MODULAR SPECIFICATIONS DESIGN
DIRECT SECURE TRANSPORT
MODULE
Office of the National Coordinator for Health Information Technology
Version 1.0
February 1, 2012
Prepared By:
ONC S&I TI/DP Team
DISTRIBUTION STATEMENT
The Design Direct Secure Transport Module Design is to be used by the Test Implementation
designers and developers to design and develop the main components of the direct secure
transport layer that can be composed to provide the specified services in a scalable,
extensible and reliable manner.
DOCUMENT CHANGE HISTORY
Version
.1
.2
1.0
Date
09/16/2011
10/05/2011
2/1/2012
Changed By
Lockheed Martin
Lockheed Martin
Lockheed Martin
Items Changed Since Previous Version
First Draft
Comments changes
Public comments
TABLE OF CONTENTS
1.0 OBJECTIVE/PURPOSE .........................................................................................................................1
2.0 REQUIREMENTS/GOALS .....................................................................................................................1
3.0
CONSTRAINTS AND ASSUMPTIONS .............................................................................................1
3.1 CONSTRAINTS ........................................................................................................................................... 1
3,2 ASSUMPTIONS .......................................................................................................................................... 2
4.0 DEPENDENCIES ...................................................................................................................................2
5.0 ARCHITECTURE ...................................................................................................................................3
5.1
DESIGN DIAGRAMS ............................................................................................................................ 3
5.2
SEQUENCE DIAGRAMS ........................................................................................................................ 4
5.2.1 Sequence Diagram Steps .......................................................................................................... 4
5.2.2 Sequence Diagram Steps- XDR ................................................................................................. 5
5.3
INTERFACES ........................................................................................ ERROR! BOOKMARK NOT DEFINED.
6.0 REFERENCES .......................................................................................................................................5
LIST OF FIGURES
FIGURE 1. PACKAGE DIAGRAM ..................................................................................... ERROR! BOOKMARK NOT DEFINED.
FIGURE 2. DESIGN MODEL ........................................................................................................................................ 3
FIGURE 4. FULL SERVICE HISP XDR DESIGN MODEL SEQUENCE DIAGRAM......................................................................... 5
1.0 OBJECTIVE/PURPOSE
This document provides a high-level design of the Test Implementation (TI) Direct Secure
Transport Module Core components. These components are used to send email securely between a
TI DIRECT email server and other Simple Mail Transfer Protocol (SMTP) mail servers.
2.0 REQUIREMENTS/GOALS
The goals of the Direct Secure Transport Module Core design are to:

Provide a design to address the functional requirements of Direct Secure Transport
Module.

Identify and define components for non-overlapping functionalities of Direct Secure
Transport Module.

Code to interfaces, not implementations.

Promote code reuse.

Achieve ease of integration.

Be extensible.

Couple loosely with other components.

Achieve ease of Unit testing and Integration testing.
3.0 CONSTRAINTS AND ASSUMPTIONS
3.1 CONSTRAINTS

The Direct Secure Transport Module is based on SMTP. The following constraints are
made on the Direct Secure Transport Module:
 Use Cross-Enterprise Document Media Interchange (XDM) - provides document
interchange using a common file and directory structure over several standard media.
This permits the patient to use physical media to carry medical documents. This also
permits the use of person-to-person email to convey medical documents.
 Use Cross-Enterprise Document Reliable Interchange (XDR) - provides document
interchange using a reliable messaging system. This permits direct document
interchange between EHRs, PHRs, and other healthcare IT systems in the absence of a
document sharing infrastructure such as XDS Registry and Repositories.
 Use Secure/Multipurpose Internet Mail Extensions (S/MIME) - which is a standard for
public key encryption and signing of MIME data. S/MIME provides the following
cryptographic security services for electronic messaging applications: authentication,
message integrity, non-repudiation of origin, privacy and data security.
11
 Be platform neutral – DIRECT uses standards that can be implemented using many
operating systems and programming languages.
3,2 ASSUMPTIONS

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.

Policy enforcement for Direct Project is out of scope for TI

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:
o
The Sender has determined that the Receiver’s address is correct.
o
The Sender has communicated to the receiver, perhaps out-of-band, the purpose for
exchanging the information.
o
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.

Multiple types of content, from unstructured (text, PDF, etc.) to semi-structured (various
CDA templates, HL7 MDM, etc.) to fully structured (CCR, CCD) will be handled.

X.509 certificates for DIRECT will be issued by a valid organization such as Verisign or
Entrust, The certificate issuance and management of DIRECT is NOT mandated by the
Office of the National Coordinator for Health Information Technology (ONC).
4.0 DEPENDENCIES
The Direct Secure Transport core components will use DIRECT common components like logging
and utilities. The DIRECT software will use the open source software Apache James as the Mail
Enterprise Server which will support SMTP and POP3 mail transfer agent. The DIRECT software
will use Apache Tomcat as the Web Server.
11
5.0 ARCHITECTURE
The intent of this design is to identify and define the interfaces the Direct Secure Transport core
exposes, the interfaces the Direct Secure Transport core uses, and to expand upon the high-level
components defined in the Direct Secure Transport Module Architecture document
5.1 DESIGN DIAGRAMS
The following diagram shows the packages where the DIRECT Secure Transport Core
components reside and the dependencies with other packages of DIRECT.
Figure 1. Design Model
Spec Factory comment: This diagram does not have a description, it is unclear exactly what is being
communicated, do the arrows imply dependencies, information flows etc?
Arrows denote information flows.
The Initiator HISP client can either send a simple email with attachment(s) or access a Web Service.
Full service HISP takes care of all encryption and signing functions and sends the message to the
Recipient HISP. There is an optional XDR to XDM conversion that takes place. At the Recipient HISP the
process is reversed, the attachment is decrypted and signature is verified. The Recipient Client can either
retrieve the message in MIME format via SMTP protocol or via the SOAP Web service. In both cases it is
a “pull” type of process as reflected by the direction of information flows.
11
5.2 SEQUENCE DIAGRAMS
The following diagram shows the sequence of operations that are performed using the Direct
Secure Transport core components.
Figure 2. Full Service HISP Design Model Sequence Diagram
Spec Factory comment: The sequence diagrams seem aligned with the specification, a written
description could be useful in future iterations.
5.2.1 SEQUENCE DIAGRAM STEPS
1. Address is discovered via DNS record
2. MIME message is sent via SMTP
11
3. Message is signed and encrypted (Note – detached signature is used as per RFC 5751)
4. Certificate of the Recipient is looked up via DNS record (as a Direct Address-bound or
Organization-bound Certificate). Please note that the certificate trust processing, i.e. validation,
revocation, etc. is implied in the Crypto module.
5. Reverse process takes place on the Recipient side: S/MIME message is decryptes, signature
validated, and a signed MDN is returned from the recipient HISP.
Figure 3. Full Service HISP XDR Design Model Sequence Diagram
5.2.2 SEQUENCE DIAGRAM STEPS- XDR
6.0 REFERENCES
The following references were used to produce this document:
11
1. Direct Transport and Security Requirements Traceability Matrix.
http://jira.siframework.org/wiki/display/MSP/Specifications+Team
2. Applicability Statement for Secure Health Transport
http://wiki.directproject.org/Applicability+Statement+for+Secure+Health+Transport
3. XDR and XDM for Direct Messaging Specification
http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging
11