The Direct Project: Sending health information over the cloud

Use Direct Sender to securely email medical records in health IT systems

Promoting interoperable and meaningful use of electronic health record (EHR) systems is one of the major goals of the federal government's healthcare reform, and the Direct Project is one of its most promising initiatives. Get started with this peer-to-peer protocol for sending sensitive patient information over the cloud, then find out how to use Direct Sender, an open source, Java-based client, to send secure email in health IT systems.


Michael J. Yuan, Chief Scientist, Ringful Health

Photo of Michael YuanDr. Yuan is a well-known technologist in the area of enterprise computing and consumer mobile technologies and a pioneer in the emerging field of consumer-driven healthcare. He is the author of five books on software engineering, and he has published over 40 articles in both peer reviewed and industry journals. Dr. Yuan's work at Ringful Health has been widely covered and recognized in national media such the Wall Street Journal, New York Times, and Los Angeles Times.

06 November 2012

Also available in Chinese Russian Japanese

Cloud computing has been a game-changer in promoting system interoperability and reducing IT costs in almost every other industry, but it has been difficult to adopt the cloud computing paradigm for health IT. Today, health IT in the cloud is mostly limited to hosted electronic health record (EHR) providers for small practices such as eClinicalWorks and PracticeFusion (see Resources). Such providers focus on hosting data and services (in the software-as-a-service or SaaS model), but not on data exchange. Large hospital systems have so far not adopted cloud computing in any meaningful way.

The potential cost saving of cloud computing could be catalytic for healthcare providers, enabling them to move toward a more efficient and open data infrastructure. Being able to securely share health data across medical systems improves the reliability of healthcare for patients. And for software developers, health IT represents a new field of innovation and discovery.

In this article, I introduce the Direct Project, a very promising protocol for sensitive data exchange, which has been developed and promoted by the United States federal government. I begin with an overview of both the need for open data exchange in health IT and the limitations of the commonly used protocols. I explain how the Direct Project fills in some of the gaps in security and infrastructure that have prevented healthcare systems from adopting more open data exchange protocols until now. Finally, I walk through a simple programming example using Direct Sender, an open source, Java-based client that implements the Direct protocol.

Health IT and open data exchange

Hospitals and physicians are notoriously bad at providing online access to patient data. Even today, in 2012, when you walk into a typical hospital in the United States and ask for your medical records, hospital staff will print them out and charge you a copy fee. When your physician needs to refer you to another healthcare provider, he or she will most likely send a fax or speak to the other provider over the phone. Such unreliable data management results in a huge amount of waste — and worse, medical error.

HIE and the Direct Project

Exchanging data among healthcare providers is such a challenge that special health information exchanges (HIE) like the Direct Project are funded by government grants. A health information exchange is an organization that provides infrastructure and services to facilitate the electronic sharing of health-related information. Each HIE typically serves a metropolitan area or part of a state. On average, it costs upward of $15 million to build an HIE, and then millions per year to keep it operational. The "closedness" of healthcare IT systems has a significant cost to all of us.

Health IT has been slow in adopting Internet technologies for many reasons. Among them are misaligned economic incentives, the highly fragmented electronic health record (EHR) market, vendor-lock-in created by EHR vendors, privacy regulations, and loose and fragmented data-exchange standards. Because of these hurdles, cloud computing has had little impact, so far, in the world of health IT. Even among healthcare providers that do have EHR implementations, it is common practice to host data internally and allow as little external access as possible.

History of the Direct Project

The United States federal government originally developed a network for health information exchange to connect DoD (Department of Defense) and VA (Veterans Affairs) hospitals so that injured soldiers could receive better care across hospitals. The system was called the National Health Information Network (NHIN). It was then taken over by the Office of National Coordinator of Health IT (ONC) and made into an open source project to serve as a template for health information exchanges across the country. ONC renamed the project to Nationwide Health Information Network (NwHIN), and then later to eHealth Exchange.

The core of the federal HIE network is a service-oriented architecture (SOA) system called CONNECT, which is based on Java ESB (see Resources). Healthcare providers in the network may plug their system into the bus. The CONNECT network can be organized in a hierarchical fashion. In practice, however, such a system is very complex to maintain and scale.

Recognizing the limits of CONNECT, the ONC next developed a scaled-down HIE infrastructure called Direct. Unlike CONNECT, Direct is designed to be peer-to-peer. Direct's open, peer-to-peer data exchange model is familiar to healthcare providers accustomed to faxing information back and forth, and is thus more likely to be widely adopted.

Email security and health IT

Patient data stored in health IT systems is subject to strict privacy and security regulations such as the Health Insurance Portability and Accountability Act (HIPAA) and the Health Information Technology for Economic and Clinical Health Act (HITECH). Together these regulations define how data should be stored and transmitted and who is responsible for data breaches.

Email is the most widely used tool for exchanging documents over the Internet. While email is pervasive, it is not secure enough for sending sensitive data such as medical records and referrals. Email addresses can be spoofed and email content passes through multiple third-party mail servers on the Internet in clear text before it reaches a recipient's Inbox. These facts are inconsistent with HIPAA and HITECH security rules.


Read "Privacy and security of patient data in the cloud" (Erin Gilmer, developerWorks, October 2012) to learn more about the legal context of HIPAA and the HITECH act and their impact on health IT.

But the pervasiveness of email has turned out to be a big draw, as first discovered by the financial industry. Long before health IT came on the scene, the financial industry had pioneered secure email to share sensitive financial information with online banking users. IETF RFC 3851 — the Secure/Multipurpose Internet Mail Extensions (S/MIME) Message Specification — defines a way to encrypt email attachments using the Public Key Infrastructure (PKI) protocol. As specified by RFC 3851, S/MIME attachments can enclose an entire email message, which is then sent over the public Internet.

While PKI is a widely accepted standard for Internet security, using PKI-based secure email presents some major hurdles:

  1. PKI requires both the message sender and recipient to have a digital certificate issued by an established authority. The digital certificate provides encryption and decryption keys for a shared message. More importantly, it establishes the identity of the sender and recipient, so that no one can spoof the message. Obtaining a person's certificate is often a lengthy and expensive process.
  2. Once the senders and recipients receive their digital certificates they need to make them discoverable on the Internet, because senders and recipients must exchange certificates before they can email each other. This problem has been partly resolved by creating a new DNS standard that stores email certificates on DNS servers, which are publicly discoverable. But most DNS services on the Internet do not implement this functionality.
  3. Both the sender and recipient must use an email client that supports S/MIME encryption and DNS certificate discovery.

Together these hurdles have greatly impeded consumer adoption of secure email. The Direct protocol is, nonetheless, a good fit for the particular use cases of secure document exchange between medical providers and patients.

Use cases in health IT

In healthcare, one of the prevailing modes of document exchange is for providers to exchange patient information with each other. Documents exchanged include referrals, medical history, insurance information, test results, medication lists, and so on. Today, healthcare providers send such documents via fax, but it makes more sense to send them via secure email.

Another common use case in health IT is for medical providers to send records directly to patients. Here, the Direct Project borrows a page from the financial industry's playbook. Instead of sending email directly to the patient, the Direct protocol would have us create an email account for each patient in the healthcare system, then send a notification email to the patient's regular account when a secure email arrived. The patient would then be required to log in to the healthcare system's patient portal and check his or her secure messages via a web-mail like interface. In this case, the secure email would be sent within the healthcare organization's internal email system.

Using Direct to send secure email

You've learned a bit about the background of secure email and the Direct Project, and hopefully you can see the benefits of implementing the Direct protocol and infrastructure in a health IT system. So let's see how we would set up that infrastructure to send a secure email. For this, you'll need a destination email address that is able to accept Direct email messages. Fortunately, we can use Microsoft HealthVault (see Resources), which provides Direct support for any individual. Start by creating an account on the Microsoft HealthVault staging server at After you've created an account, you will have a Direct-enabled secure email address at You can test your code by sending email to that address.

About Microsoft HealthVault

Microsoft HealthVault is a Personal Health Record (PHR) system. It allows patients/consumers to enter and manage their own medical records. HealthVault is connected to the medical records of several large hospital systems.

Next, you will need to create a public key digital certificate that you'll use to digitally sign your email message. The public key digital certificate ensures email recipients that a sent message is really from you. You will need a digital certificate for every sender address. One option is to get a trusted digital certificate from a certificate authority such as Verisign and put it in your DNS record for a recipient to discover. HealthVault has made it even easier by allowing you to simply create a self-signed certificate and then email it to The HealthVault team will load the certificate as trusted. Self-signed certificates make it much easier for developers to experiment with the Direct system.

It's easy to generate a private/public key pair and digital certificate using a tool like the Apple Keychain. Listing 1 shows commands from the popular openssl tool available on almost all common operating systems.

Listing 1. Creating a public/private key pair with openssl
openssl req -new -newkey rsa:2048 -nodes -keyout private.key

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout private.key -out public.crt

openssl pkcs12 -export -in public.crt -inkey private.key -out bundle.p12

The first command in Listing 1 creates a private key that you can use to sign and encrypt your messages. The second command creates a public key digital certificate for the recipient to decrypt and verify your messages. And the third command creates a PKCS12 bundle of the private and public key pair, which you can conveniently use in your application. You may be asked to enter a name and a passcode for the private key in the bundle.

Emailing the public.crt file to Microsoft HealthVault will alert the system to trust messages signed by your private key.

Direct Sender

Direct Sender is an open source library that I've created to make it easier to send Direct mail. Direct Sender is hosted on GitHub, where I've also provided a Quick Start tutorial. The library supports multiple ways of sending email, from using an SMTP server that you host yourself, to Gmail servers, to specialized transactional email services like the Amazon Web Service Simple Email Service and SendGrid. Using the library, it takes a couple of lines of code to send a secure email message via Gmail, as shown in Listing 2:

Listing 2. Sending a secure message via Gmail
Client client = new GmailClient (
                username, password,
                "/bundle.p12", keyname, keypass);

client.sendMessage(from, to, subject, body);

In Listing 2, username and password refer to credentials for the Gmail account used to send a secure email. The bundle.p12 is the PKCS12 file created in Listing 1. Be sure that this file is in the classpath of your application. The keyname and keypass are the name and passcode of the private key in the bundle.

After you've sent a secure message, you should receive a notification email from HealthVault about a new message in your Inbox. Log into HealthVault to see the message.

Direct Sender under the hood

You've seen how to use the Direct Sender library. But what is happening under the hood when we encrypt and send a message in a Direct-compliant format? Several open source Java libraries do the heavy-lifting for Direct Sender:

  • Bouncy Castle is a well-known open source implementation of the Java Cryptography Extension (JCE), which provides essential tools for PKI support on the Java platform. It also provides add-ons such as S/MIME encryption utilities.
  • javamail.crypto supports incorporating S/MIME attachments into the JavaMail Transport API.
  • dnsjava is a Java-based DNS client that is capable of querying digital certificates for email addresses stored in a DNS record.

The Java Client abstract class supports the basic functionalities of signing, encrypting, and creating a S/MIME email. Notice in Listing 3 that I've signed the message with a private key first, and then used the recipient's public key certificate to encrypt the message. When the recipient receives the message, HealthVault will use the recipient address's private key to decrypt it first, and then use the sender's public key (assuming it has been emailed to HealthVault) to verify the sender's identify.

Listing 3. Client handles message signature and encryption
public abstract class Client {
    protected String p12KeyStore;
    protected String priKeyName;
    protected String priKeyPass;
    public void sendMessage (String from, String to, String subject, String body) 
      throws Exception {
        byte [] pubKeyCer = lookupCertificate (to);
        if (pubKeyCer == null || pubKeyCer.length == 0) {
            throw new Exception ("Cannot find public key certificate for " + to);
        Session session = createSession ();
        MimeMessage msg = new MimeMessage(session);
        msg.setFrom(new InternetAddress(from));
        msg.setSender(new InternetAddress(from));
        msg.addRecipient(javax.mail.Message.RecipientType.TO, new InternetAddress(to));
        msg = signMsg(session, msg);
        msg = encryptMsg(session, msg, pubKeyCer);
        transport(session, msg);
    public void sendMessage (String from, String to, String subject, Multipart multipart) 
      throws Exception {
        byte [] pubKeyCer = lookupCertificate (to);
        if (pubKeyCer == null || pubKeyCer.length == 0) {
            throw new Exception ("Cannot find public key certificate for " + to);
        Session session = createSession ();
        MimeMessage msg = new MimeMessage(session);
        msg.setFrom(new InternetAddress(from));
        msg.setSender(new InternetAddress(from));
        msg.addRecipient(javax.mail.Message.RecipientType.TO, new InternetAddress(to));
        msg = signMsg(session, msg);
        msg = encryptMsg(session, msg, pubKeyCer);
        transport(session, msg);
    protected byte [] lookupCertificate (String email) {
        try {
            String domain = email.replaceAll("@", ".");
            CERTRecord cx = null;
            Record [] records = new Lookup(domain, Type.CERT).run();
            for (int i = 0; i < records.length; i++) {
                cx = (CERTRecord) records[i];
            if (cx == null) {
                return null;
            } else {
                return cx.getCert ();
        } catch (Exception e) {
            e.printStackTrace ();
            return null;
    protected MimeMessage encryptMsg(Session session, MimeMessage msg, byte [] pubKeyCer) 
      throws Exception {
        EncryptionUtils encUtils = EncryptionManager.getEncryptionUtils
        CertificateFactory cf = CertificateFactory.getInstance("X.509");
        X509Certificate cert = (X509Certificate)cf.generateCertificate
          (new ByteArrayInputStream(pubKeyCer));
        // wrap certificate in BouncySMIMEEncryptionKey 
        BouncySMIMEEncryptionKey smimekey = new BouncySMIMEEncryptionKey();

        return encUtils.encryptMessage(session, msg, smimekey);
    protected MimeMessage signMsg(Session session, MimeMessage mimeMessage) throws 
    Exception {
        // Getting of the S/MIME EncryptionUtilities.
        EncryptionUtils encUtils = EncryptionManager.getEncryptionUtils

        // Loading of the S/MIME keystore from the file (stored as resource).
        char[] keystorePass = priKeyPass.toCharArray();
        EncryptionKeyManager encKeyManager = encUtils.createKeyManager();

        // Getting of the S/MIME private key for signing.
        Key privateKey = encKeyManager.getPrivateKey(priKeyName, keystorePass);

        // Signing the message.
        return encUtils.signMessage(session, mimeMessage, privateKey);
    protected abstract Session createSession ();
    protected abstract void transport (Session session, MimeMessage msg) throws Exception;

Next, the GmailClient class, shown in Listing 4, implements the Java createSession() and transport() methods, which support the ability to send email through the Gmail servers:

Listing 4. Secure email via Gmail
public class GmailClient extends Client {

    String username, password;
    public GmailClient (String username, String password, String p12KeyStore,
     String priKeyName, 
      String priKeyPass) {
        super.p12KeyStore = p12KeyStore;
        super.priKeyName = priKeyName;
        super.priKeyPass = priKeyPass;
        this.username = username;
        this.password = password;
    protected Session createSession() {
        Properties props = new Properties();
        props.put("", "");
        props.put("mail.smtp.socketFactory.port", "465");
        props.put("mail.smtp.socketFactory.class", "");
        props.put("mail.smtp.auth", "true");
        props.put("mail.smtp.port", "465");
        return Session.getDefaultInstance(props,
                new javax.mail.Authenticator() {
                    protected PasswordAuthentication getPasswordAuthentication() {
                        return new PasswordAuthentication(username, password);

    protected void transport(Session session, MimeMessage msg) throws Exception {
        Transport transport = session.getTransport("smtp");

Receiving Direct email

Using the Direct protocol for secure email along with the Direct Sender client enables a physician's office to easily and securely send referrals and test results to hospitals and patients. We could also use it enable mobile health (mHealth) applications to send data collected from a patient into his or her digital medical record. For many healthcare applications, the ability to send Direct mail is the only requirement. In a much rarer case, your application could need to be able to receive secure email.

Most large hospital EHRs will not send out patient records without extensive business and technical audits, so it would be unusual for a small health IT system to receive secure email. Receiving secure email from another electronic medical record system is also more complicated than simply sending it. To receive medical records from a hospital EHR, you would most likely establish a direct XML-over-HTTPS connection using a standard technology such as the HL7 (Health Level Seven International) framework (see Resources).

If you do need to develop an in-house infrastructure for receiving Direct email from another healthcare provider, then you will need to do at least the following:

  1. Create a business associate agreement with the healthcare provider that will be sending you data. This can be a lengthy process, and it creates liability for both parties.
  2. Set up an email infrastructure that can automatically decrypt and verify incoming email messages, then present such messages to recipients behind a firewall.

The first requirement is a business requirement and the second one is technical. To assist IT administrators in setting up their own Direct email infrastructure, the Direct Project supports open source reference implementations of email gateway servers that are capable of handling Direct messages. Reference implementations are provided for Java EE, Microsoft .Net, and PHP frameworks (see Resources).

In conclusion

With support from the federal government and many healthcare systems, the Direct Project is well positioned to become the de facto standard for exchanging simple healthcare documents such as referrals, insurance information, test results, and medical history. It is built on top of existing, pervasive email infrastructure, but its adoption depends on healthcare providers updating their IT systems to support secure email standards. As a software developer working in health IT, you may soon find the Direct protocol an indispensable tool for securely sending electronic medical records.

See Resources to learn more about Direct and the Java-based Direct Sender secure email client, which is hosted on GitHub.



  • See the Direct Project homepage for more information about the Direct Project and active pilot sites.
  • If your application requirements include receiving Direct secure emails, the Direct RI provides email servers implemented for the Java platform, .Net, and PHP.
  • Learn more about setting up your application as a trusted sender for Direct email into Microsoft HealthVault.
  • "Privacy and security of patient data in the cloud" (Erin Gilmer, developerWorks, October 2012): Learn more about HIPAA (Health Information Portability and Accountability Act) and the HITECH (Health Information Technology for Economic and Clinical Health) act and their impact on health IT.
  • Read more of Dr. Yuan's articles on developerWorks:
  • Also see Dr. Yuan's industry blog on developerWorks: Innovations in Health IT.
  • "The $10M investment in DIRECT from eClinicalWorks" (Michael Yuan, Innovations in Health IT, September 2012) discusses how EHR systems like eClinicalWorks are investing in the Direct Project.
  • Learn more about Public Key Infrastructure with "PKI: A primer" (Joe Rudich, developerWorks, December 2000).
  • "Enhancing e-mail security with S/MIME" (Chuck Connell, developerWorks, December 2001) introduces the Secure Multipurpose Internet Mail Extension protocol and the role of public key cryptography in S/MIME authentication.
  • The National eHealth Collaborative is a public-private collaborative that drives the development and adoption of health information exchanges. It is the umbrella organization for the federal Connect and Direct projects.
  • The Direct secure email standard is based on RFC 3851— IETF's S/MIME standard.
  • The IETF standard for storing digital certificates in DNS servers enables secure email recipients to validate a sender id.
  • Bouncy Castle is an open source provider to the Java Cryptography Extension (JCE). It also provides support for S/MIME.
  • The JavaMail-Crypto API is an API extension to JavaMail to manage encrypted email.
  • The DNSJava project provides Java APIs to interact with DNS servers. It includes support for email certificates stored in the DNS system.
  • Amazon Simple Email Service and SendGrid are two transactional email services that can be used as transports to send Direct messages.
  • Follow developerWorks on Twitter.
  • Watch developerWorks on-demand demos ranging from product installation and setup demos for beginners, to advanced functionality for experienced developers.

Get products and technologies

  • Direct sender is an open source Java client implementing the Direct protocol. Direct Sender simplifies the process of sending Direct secure emails in health IT systems.
  • Microsoft HealthVault is one of the leading personal health record (PHR) systems that supports the Direct protocol.
  • OpenSSL is an open source tool for generating the private and public keys and certificates required for secure email.
  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Cloud computing on developerWorks

  • developerWorks Premium

    Exclusive tools to build your next great app. Learn more.

  • Cloud newsletter

    Crazy about Cloud? Sign up for our monthly newsletter and the latest cloud news.

  • Try SoftLayer Cloud

    Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.

Zone=Cloud computing, Java technology, Open source
ArticleTitle=The Direct Project: Sending health information over the cloud