MODULAR ARCHITECTURE
DIRECT SECURE TRANSPORT
MODULE
Office of the National Coordinator for Health Information Technology
Version .4
October 5, 2011
Prepared By:
ONC S&I RI/DP Team
DISTRIBUTION STATEMENT
The Direct Secure Transport Module Architecture is to be used by the Reference
Implementation designers to define the main components of the Direct transport layer that
can be composed to provide the specified services in a scalable, extensible and reliable
manner.
DOCUMENT CHANGE HISTORY
Version
.1
.2
.3
.4
Date
08/22/2011
08/25/2011
09/06/2011
10/5/2011
Changed By
Lockheed Martin
Lockheed Martin
Lockheed Martin
Lockheed Martin
i
Items Changed Since Previous Version
First draft
Changes from peer review comments
Additions for scope change
Comments changes
Modular Pilot Architecture Direct Transport Module
TABLE OF CONTENTS
1.0
1.1
1.2
1.3
1.4
2.0
INTRODUCTION ..................................................................................................................................... 1
OVERVIEW ..................................................................................................................................................1
SCOPE ........................................................................................................................................................1
PURPOSE.....................................................................................................................................................2
GOALS ........................................................................................................................................................3
CONTEXT ............................................................................................................................................... 4
2.1
DOMAIN .....................................................................................................................................................4
2.2
GUIDING PRINCIPLES .....................................................................................................................................4
2.3
VISION ........................................................................................................................................................4
2.4
STRATEGY....................................................................................................................................................4
2.5
MISSION/BUSINESS DRIVERS ..........................................................................................................................7
2.5.1 Creation ...............................................................................................................................................7
2.5.2 Decisions ..............................................................................................................................................7
2.6
CONSTRAINTS AND ASSUMPTIONS....................................................................................................................7
2.7
BENEFITS.....................................................................................................................................................9
3.0
CONTENT .............................................................................................................................................. 9
3.1
REQUIREMENTS AND FEATURES .......................................................................................................................9
3.2
SPECIFIC KEY DRIVERS....................................................................................................................................9
3.3
PERFORMANCE CRITERIA ..............................................................................................................................10
3.4
SYSTEM PLATFORM .....................................................................................................................................10
3.4.1 Java Reference Implementation Components ...................................................................................10
3.4.2 Direct Secure Transport Module – Deployment Models ....................................................................11
3.4.4 e-Mail client using Native S/MIME ....................................................................................................12
3.4.6 STAgent Components ........................................................................................................................14
3.5
STANDARDS ...............................................................................................................................................15
3.6
STAKEHOLDERS...........................................................................................................................................15
APPENDIX A: REFERENCES ............................................................................................................................... 16
LIST OF TABLES
TABLE 1. HIGH-LEVEL TRANSPORT MODULE COMPONENTS ........................................................................................................1
TABLE 2. RFCS REFERENCED BY DIRECT SECURE TRANSPORT MODULE .........................................................................................2
TABLE 3. DIRECT DEPLOYMENT MODELS...............................................................................................................................12
ii
Modular Pilot Architecture Direct Transport Module
LIST OF FIGURES
FIGURE 1. E-MAIL CLIENT WITH FULL SERVICE HISP .................................................................................................................5
FIGURE 2 DIRECT PROJECT SENDING TO XDR WITH TRUSTED SERVICE PROVIDER ............................................................................6
FIGURE 3. REFERENCE IMPLEMENTATION COMPONENTS DIAGRAM ............................................................................................11
FIGURE 4. E-MAIL CLIENT USING NATIVE S/MIME .................................................................................................................13
FIGURE 5. STAGENT COMPONENTS .....................................................................................................................................14
iii
Modular Pilot Architecture Direct Transport Module
1.0 INTRODUCTION
This document provides a high-level architectural perspective of the Reference Implementation
(RI) Direct Secure Transport Module developed by the Office of the National Coordinator for Health
Information Technology (ONC) as part of the Direct Project. The Direct Project develops
specifications for a secure, scalable, standards-based way to establish universal addressing and
transport method for participants (including providers, laboratories, hospitals, pharmacies and
patients) of sending encrypted health information directly to known, trusted recipients over the
Internet. The Nationwide Health Information Network is a set of standards, services and policies
that enable secure health information exchange over the Internet. The project itself does not
implement health information exchange services. The Direct Project will expand the standards and
available service definitions to address the key Stage 1 requirements for Meaningful Use, and
provide an easy "on-ramp" for a wide range of providers and organizations looking to adopt them.
1.1 OVERVIEW
The Direct Secure Transport Module Architecture defines the transport mechanism components
and interfaces. It consists of the components shown in Table 1.
Table 1. High-level Transport Module Components
Component
Agent
Client
Certificate Discovery Service
XD*
Purpose
Encryption, Discovery & Validation of Trust,
Signing
Mailer, Locates Destination Address
Certificate Discovery
Document Processing
1.2 SCOPE
The scope of this architecture is defined by Applicability Statement for Secure Health Transport
document and the XDR and XDM for Direct Messaging Specification.
The XDR and XDM for Direct Messaging Specification Section 3.0 has a table that lists nine types
of interaction of two IHE specifications (Cross-Enterprise Document Media Interchange (XDM) and
Cross-Enterprise Document Reliable Interchange (XDR)) and the Direct Project SMTP/RFC 5322
specification. The Direct Secure Transport Architecture will describe the use of the Sender using
RFC 5322 + Multipurpose Internet Mail Extensions (MIME) with the Receiver using RFC 5322 +
MIME. The second scenario, in which the Sender uses RFC 5322 + MIME and the Receiver uses
SOAP+XDR, will also be implemented.
The Applicability Statement for Secure Health Transport describes how to use Simple Mail
Transfer Protocol (SMTP), Secure MIME (S/MIME) and X.509 certificates to securely deliver health
information over the Internet. Participants in the exchange are identified using standard e-mail
addresses along with associated X.509 certificates. The data is packaged using standard MIME
1
Modular Pilot Architecture Direct Transport Module
content types. Authentication and privacy are enforced by using Cryptographic Message Syntax
(S/MIME), and confirmation delivery is performed using encrypted and signed Message Disposition
Notification. Optionally, certificate discovery is accomplished through the use of the DNS
(Certificate Discovery is out of scope for this project). Advice is given in the specification for specific
processing to ensure security and trust validation on behalf of the ultimate message originator or
receiver.
The XDR and XDM for Direct Messaging specification addresses the use of XDR and XDM zipped
packages in e-mail in the context of directed messaging to fulfill the key user stories of the Direct
Project. In this specification, XDM always means the XDM e-mail transport option defining how to
pack/unpack a directory of a file system in a zip archive and deliver it as an S/MIME attachment.
1.3 PURPOSE
The purpose of the Direct Secure Transport Module described by this architecture is to promote
modularization, and to provide consistency in applying technology to the solution designs. ONC has
applied a modular architectural approach to the analysis of specifications in order to achieve
interoperability among evolving parts of the Standards and Interoperability (S&I) Framework.
This document is intended as an applicability statement providing constrained conformance
guidance on the interoperable use of a set of Request for Comments (RFCs) (See Table 2 for RFCs)
describing methods for achieving security, privacy, data integrity, authentication of sender and
receiver, and confirmation of delivery, that is consistent with the data transport needs for Health
Information Exchanges (HIEs).
Table 2. RFCs Referenced by Direct Secure Transport Module
RFC Number
768
RFC Description
User Datagram Protocol
1034
Domain Names – Concepts and Facilities
1847
Security Multi-parts for MIME: Multipart/Signed and Multipart/Encrypted
2045
Multipurpose Internet Mail Extensions (MIME) Part One: Format of
Internet Message Bodies
2046
Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
2387
The MIME Multipart/Related Content-type
2560
X.509 Internet Public Key Infrastructure Online Certificate Status Protocol
- OCSP
2
Modular Pilot Architecture Direct Transport Module
RFC Number
RFC Description
3370
Message Digest Algorithms
3565
Use of the Advanced Encryption Standard (AES) Encryption
Algorithm in Cryptographic Message Syntax (CMS)
3798
Message Disposition Notification
3851
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1
Message Specification
4034
Resource Records for the DNS Security Extensions
4398
Storing Certificates in the Domain Name System (DNS)
4510
Lightweight Directory Access Protocol (LDAP):Technical Specification
Road Map
4648
Base-N Encodings
5260
Sieve Email Filtering: Date and Index Extensions
5280
Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile
5322
Internet Message Format
5652
Cryptographic Message Syntax (CMS)
5731
Extensible Provisioning Protocol (EPP) Domain Name Mapping
5751
S/MIME 3.2 Message Specification
1.4 GOALS
The goals of the RI Direct Secure Transport architecture are to:

Provide a modular design that promotes the validation of building blocks comprising
the Secure Transport subsystem.

Identify a uniform approach to the analysis and design of other Reference
Implementation subsystems.
3
Modular Pilot Architecture Direct Transport Module

Provide guidance on interconnecting the components in a scalable and individually
testable manner.

Enable ease of Integration.

Promote extensibility.

Allow for loose coupling with other modules.
2.0 CONTEXT
The Direct Secure Transport Module is foundational to the software system that enables
participation of any organization in the Direct Project.
2.1 DOMAIN
The specifications cover inter-organizational communications, the encoding of information,
application of regulatory and legal restrictions on the disclosure of personal health and care
information, and business logic pertaining to the meaningful use of such information.
The Direct Secure Transport Module Architecture defines the communications that support the
exchange of health data among participants in the Direct Project.
2.2 GUIDING PRINCIPLES
The guiding principles are those of enterprise software integration, abstraction of external
dependencies, provision for future extension, programming to contracts, and portability between
operating environments.
At the level of Direct component design, the guiding principles are those of object orientation and
the use of proven patterns and algorithms.
2.3 VISION
This architecture serves to insulate each organization from the need to know specific details of
the capabilities and operations of its peer organizations.
2.4 STRATEGY
The Direct Secure Transport Module Architecture is based on the SMTP and S/MIME. The module
is agnostic to a specific operating system or programming language framework.
In modules where the Direct Project depends on the functionality of the hosting organization in
respect to such matters as user authentication or enforcement of access consent policy; those will
be defined abstractly so that they can be implemented according to the needs and capabilities of the
organization.
Loose coupling of foundational components will allow them to be maintained, revised, rewritten,
or replaced with minimal disturbance to the system as a whole.
4
Modular Pilot Architecture Direct Transport Module
The deployment models constitute a common platform for secure and reliable exchange of
messages between organizations in a manner that is independent of specific operating system or
programming language framework.
The Direct Secure Transport Module Architecture is based on the following conceptual model.
Figure 1. e-Mail Client with Full Service HISP
A) e-Mail client with Full Service HISP
Source Client
Document
Or
XDM
Source
Full Service HISP
A.3
Destination
Full Service HISP
Document
Or
XDM
Locate
Destination
Certificate
A.10 POP/IMAP +
A.1
TLS
A.4
Locate
Destination
Address
A.2
Destination Client
S/MIME
Sign
w/ Private Key
S/MIME Verify
w/ Source Cert
Private
Key
Store
SMTP +
MIME+
TLS
Private
Key
Store
A.8
S/MIME
Encrypt
w/ Destination
Cert
Send
A.9
S/MIME Decrypt
w/ Private Key
A.5
A.6
A.11
Encrypted
Content
A.7
SMTP +
S/MIME
Receive
Model A uses common e-mail functionality with a Health Information Service Provider (HISP)
service that accepts all outbound/inbound e-mail messages. This HISP service is fully trusted and
will apply the security function to encrypt and sign outbound e-mail; and decrypt and validate
signatures on inbound e-mail. The main advantage of this model is that it shifts the complexity of
the security function to an external service.
5
Modular Pilot Architecture Direct Transport Module
The RI Team will also implement the following model.
Figure 2 Direct Project Sending to XDR with Trusted Service Provider
E) Direct Project sending to XDR with Trusted
Service Provider (e.g. NHIN Exchange)
Gateway: Direct Project to XDR
(Destination HISP)
Endpoint
in XDR
Exchange
E.1.7
Convert XDM
metadata and
content to XDR
format
XDR
+ TLS
E.1.6
E.1.5
S/MIME Verify
w/ Source Cert
Address
Book w/
Certs
E.1.4
S/MIME Decrypt
w/ Private Key
Direct
Project
Sender
E.1.2
SMTP +
S/MIME
E.1.1
Receive
E.1.3
Private
Key
Store
Destination Certificate
is shared with all XDR
destinations in XDR
Exchange
There are HIEs that use XDR for push workflows. These HIEs would like to send and to receive
messages from participants that are using the Direct Project Specification. Model E1 shows how this
can happen in an integrated fashion. The main advantage of integrating these two specifications is
that two different protocols can be used without changes to either endpoint.
The additional Direct models are not considered to be within the scope of the Modular
Specifications Direct Secure Transport.
6
Modular Pilot Architecture Direct Transport Module
2.5 MISSION/BUSINESS DRIVERS
2.5.1 CREATION
The Foundation Specifications were developed in order to promote these ONC objectives:

interoperability

transparent and timely
exchange of significant clinical
information among care-givers,
scientific organizations, and
government

respect for patient
confidentiality and control

reduced medical costs

improved clinical outcomes

better epidemiological science
2.5.2 DECISIONS
The decision to define reasonably granular component architecture has been taken in response
to feedback from the community, and after applying best-known software engineering practices to
the analysis of the prior implementations of comparable technologies.
2.6 CONSTRAINTS AND ASSUMPTIONS
The context in which the Direct Project operates imposes certain constraints and assumptions on
the Direct architecture. These constraints and assumptions are detailed in this section.
The Direct Project allows secure communication of health data between health care participants
who already know and trust each other and thus are bound by a set of simplifying assumptions. The
Direct Project assumes that the sender is responsible for enforcement of minimal requirements
before sending data, including the collection of patient consent, where appropriate. These
requirements may or may not be handled electronically, but they are handled nonetheless, even
when sharing information via paper or fax. For example, a sender may call to ask whether a fax was
sent to the correct fax number and was received by the intended receiver. This is sometimes
referred to as “out of band” verification.
The following assumptions provide context for the Direct Project’s standards and services:
1. Policy guidance for Direct Project exchange will be provided by the Nationwide Health
Information Network Workgroup of the HIT Policy Committee and it is not a concern of the
Direct Project itself. Organizations must choose the policies and practices that support their
specific environments.
2. Policy enforcement for Direct Project is out of scope for RI.
3. Direct Project exchange will conform to applicable federal and state laws, including but not
limited to those related to security and privacy of protected health information.
4. As required by law or policy, the Sender has obtained the patient’s consent to send the
information to the Receiver. Therefore, the Sender and Receiver know that the patient’s
privacy preferences are being honored.
7
Modular Pilot Architecture Direct Transport Module
5. The Sender of a Direct message has determined that it is legally appropriate to send the
information to the Receiver through out-of-band means.

The Sender has determined that the Receiver’s address is correct.

The Sender has communicated to the receiver, perhaps out-of-band, the purpose for
exchanging the information.

The Sender and Receiver do not require common or pre-negotiated patient identifiers.
Similar to the exchange of fax or paper documents, there is no expectation that a
received message will be automatically matched to a patient or automatically filed in
an EHR.
The Direct Project solution provides a way to communicate in a secure, private, and reliable way,
as described in the detailed Direct Project technical specifications. These specifications define what
can be done to validate the identity of the sender and ensure the authenticity and integrity of the
content sent, but they do not describe what needs to be done to assert that the sender or receiver
has met the policy assumptions mentioned above.
2.7 BENEFITS
This architecture will help to ensure that all participating organizations in the Direct Project
conform to the S&I Framework Foundation Specifications, which in turn helps to promote
interoperability among participants. Interoperability results in improved clinical care and medical
outcomes, advances in epidemiological science, and reaching other objectives.
The modularity of this architecture, and its logical separation from and abstraction of the
architectures of other Foundation Specifications, enables the implementation of any of the
Foundation Specifications without entanglement with the others or with the specifications
governing business use cases.
3.0 CONTENT
3.1 REQUIREMENTS AND FEATURES
Requirements and features of the Direct Secure Transport Module are defined by the Modular
Specifications Requirements Traceability Matrix (RTM) and referenced profiles and supplements as
well as by Industry standards identified in the RTM.
3.2 SPECIFIC KEY DRIVERS

The Direct Project is in need of both well-defined, independently implementable,
extensible component architecture and accurate open-source implementations of
those specifications.
9
Modular Pilot Architecture Direct Transport Module

The ONC foresees and desires a much higher number of prospective participant
organizations that, prior to certification for participation, will install and configure the
Direct Project software.

The ONC desires to establish an open-source development community, to continue the
development of the Direct Project software and new business use cases.
3.3 PERFORMANCE CRITERIA
The current industry standards for portable, extensible software include both the .NET platform
and Java. Both frameworks provide extensive support in the areas that ONC has mandated as
essential aspects of the Direct Project, such as platform independence, modular testability,
scalability, reliability and support for standards-based development, particularly in the services
domain. The Framework has not specified performance criteria for this component or for Direct.
However, the Reference Implementations of the Direct Secure Transport Specifications are
intended to form the basis for an on-going open-source development community aimed at
producing Direct software suitable for use in a real-world production environment.
The performance goals will be set based on e-mail message traffic statistical analysis expected to
be performed in the Production setting of the Direct Project.
3.4 SYSTEM PLATFORM
3.4.1 JAVA REFERENCE IMPLEMENTATION COMPONENTS
The Direct Project is comprised of systems conforming to interoperability standards available on
the Direct website, assembled so that they can exchange health information in a secure manner.
Direct Secure Transport Module is one of the many components that constitute the Direct Project.
10
Modular Pilot Architecture Direct Transport Module
Figure 3. Reference Implementation Components Diagram
Conceptually the RI Components can be divided into the following sections:

SMTP Server handles the Inbound, Outbound, and SMTP messages

HISP contains the main processing logic. The XD* SOAP endpoints are out of scope
from this document.

Mailet API is used to communicate with eMail Clients. (The Apache James Mailet API
specifies mailets.)

Email Clients are the endpoints with which the Direct Secure Transport
communicates.
3.4.2 DIRECT SECURE TRANSPORT MODULE – DEPLOYMENT MODELS
The following Direct Deployment Models are defined for the Direct Project.
11
Modular Pilot Architecture Direct Transport Module
Table 3. Direct Deployment Models
Direct Deployment Model
Base Transport
Security and Other Issues
Model A (client using HISPs)
SMTP+S/MIME
Crypto: MIME to S/MIME
SMTP+MIME over TLS
Crypto: S/MIME to MIME
POP/IMAP over TLS
Model B (client has smart mail)
SMTP+S/MIME
POP/IMAP over TLS
Model C (http interface)
SMTP+S/MIME
HTTP pages to collect envelope
and data, convert to XDM,
package as S/MIME and deliver
to other side. Reverse the
process for the receiver.
HTTP over TLS
Model D (receiver has smart SAME AS Model B
mail)
Model E (complex connections SMTP+S/MIME
with NHIN and XDR exchanges)
XDR over TLS
Complex application with two
options,
The Direct Secure Transport Module implements Model A and Model E1 in this specification. All
other Models are out of scope in this specification and will be implemented in a later version.
3.4.4
E-MAIL CLIENT USING NATIVE S/MIME
The following diagram depicts, at a conceptual level, the components and interfaces that will
comprise the Direct Deployment Model A – eMail client with Full Service HISP.
12
Modular Pilot Architecture Direct Transport Module
Figure 4. e-Mail Client using Native S/MIME
13
Modular Pilot Architecture Direct Transport Module
3.4.6 STAGENT COMPONENTS
Figure 5. STAgent Components
3.4.6.1 Security and Trust Agent (STAgent)
DirectProjectCertGenerator – DIRECT tool that generates a certificate to be used by the HISPs. The
certificates must be exchanged and trusted by the HISPs.
TrustResolver – Resolves the Certificates as trusted or untrusted.
Message Disposition Notification – Notifies the sender that the email has been received by the HISP. This
does not imply that the receiver has ‘read’ the email.
Cryptography – consists of several components that are used to sign and encrypt the message.
14
Modular Pilot Architecture Direct Transport Module
3.4.6.2 Flow Sequence – e-Mail Client with Full Service HISP
The following sequence of steps occurs when an e-mail is sent from one organization to another
organization.
1. Source Client locates destination address.
2. Using SMTP + MIME + TLS, the Source Client locates destination Certificate of Source Full
Service HISP.
3. Source Full Service HISP uses S/MIME to sign the message with the Private key.
4. Source Full Service HISP uses S/MIME to encrypt message with Destination Certificate.
5. Message sent to Destination Full Service HISP using SMTP + S/MIME.
6. Destination Full Service HISP receives message.
7. Destination Full Service HISP uses S/MIME and private key to decrypt message.
8. Destination Full Service HISP uses S/MIME to verify with Source Certificate.
9. Destination Client uses POP/IMAP + TLS to retrieve message.
3.5 STANDARDS

Applicability Statement for Secure Health Transport

XDR and XDM for Direct Messaging Specification
3.6 STAKEHOLDERS

ONC

The Nationwide Health Information Network participants

Free Open Source Software (FOSS) Community

Direct Project Participants
15
APPENDIX A: REFERENCES
The following references were used to produce this document:

Direct Transport and Security Requirements Traceability Matrix.
http://jira.siframework.org/wiki/display/MSP/Specifications+Team

Applicability Statement for Secure Health Transport
http://wiki.directproject.org/Applicability+Statement+for+Secure+Health+Transport

XDR and XDM for Direct Messaging Specification
http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging