April 06, 2012

The Direct Project: A modular view - part one

By: Greg Meyer, director, principal architect, Cerner

Over the past month, I've taken on the daunting task of compiling my knowledge of the technical ins and outs of the Direct Project into an online developer's handbook to assist both my Cerner brethren and third party developers who have chosen Cerner Direct as their full-service health information service provider (HISP). As I looked back over the content, I realized there is a lot of material that is useful to a broader audience in the Direct community. So in the spirit of knowledge sharing, I'm sharing my insight (wisdom?) in a series of blog posts.

In this post, I’ll summarize the Direct Project and discuss HISPs and HISP components. Part two will continue the discussion of HISP components, focusing on security and trust. Part three will look at edge clients and protocols, as well as policy.

The Need for Simple Information Exchange

Oversimplified and in the proper context, health information exchange is the transfer of health care information from one system to another. The systems may be located within a single health information organization (HIO), but in many cases they are discrete, separate systems residing in completely different geographies.

In a blog entry, Gartner’s Wes Rishel shares some thoughts regarding the need for a simpler information exchange protocol, which he initially called Simple Interop. His comments outline broad topics, but one notable feature is removing the need for a "query-response" infrastructure (historically complex) and creating a standard method for simple point-to-point transmission to known/trusted endpoints. Although endpoints would need to be known before transmission could commence, the endpoints would be universally addressable on the public internet like URIs or email addresses.

One example where Simple Interop could immediately provide value is the electronic sending of documents over telephone lines. Tech elders would recognize this as faxing. Several different instances of the exchange of health care information could take advantage of this, including:

Primary care provider referring a patient to a specialist including summary care record
Sending of lab results to an ordering provider
Provider sending health information to a patient
Primary care provider sending a patient's immunization data to public health entity

If only a simple method of electronic exchange could be defined in a set of standards. Behold the Direct Project.

The Direct Project

Simply put, the Direct Project is a set of specifications and standards. It specifies a simple, secure, scalable, and standards-based method for participants to send authenticated, encrypted health information directly to known, trusted recipients over the internet. At its core, it defines a security and transport protocol for exchanging information independent of exchange payload content. Combined with pre-negotiated, structured payloads between endpoints, innovative workflows can be implemented on top of Direct to meet requirements of Stage 1 and Stage 2 Meaningful Use.

Direct Components

An early philosophy of Direct was to build on top of existing standards already ubiquitously deployed. What better way to design an infrastructure that could be quickly implemented and rolled out if a large portion of the work was already done for you? And to add icing to the cake, it was already built for scalability and readily available to a global community. These were driving factors that lead to the final specification of the Direct protocol, defined in a document called the Applicability Statement for Secure Health Transport. Direct is a set of standards, but what are those standards, and how do they translate into tangible components? The standards break out into five concepts:

Backbone transport and universal addressing
Messaging gateway
Security and trust
Edge protocols
Source and destination clients

The following illustration is a typical architectural diagram of the Direct Project. Don't worry about terms at this point; they will be covered later in detail.

Health Information Service Providers

Before getting into the nuts and bolts of Direct concepts, a key term needs to be defined. All of the components in the previous section work together to provide the functionality of Direct, but who or what provides and hosts these services? Is there an enchanted black box sitting in the ether waiting to accept your messages and magically transport them to land of data tranquility? As much as it sometimes appears that way, it takes something a little more concrete to achieve technological nirvana. In Direct, this mysterious entity that powers data exchange is called a HISP.

A HISP is a logical concept that encompasses certain services required for Direct data exchange. In a concrete instance, a HISP hosts all of the components and services necessary for a participant in information exchange to send and receive data. In some instances, a HISP is a separate business entity that may or may not have a stake in the information that moves through the system. Another way to think of a HISP is like your internet service provider (ISP). Your ISP hosts and provides you with services such as a network connection, internet address allocation, email, news, and possibly a slew of other multimedia options. A HISP provides a participant in Direct with the same type of value, except the services are Direct concepts such as universal addresses, certificate management, security, trust management, and information transport.

Backbone Transport

Since a HISP can host services for multiple Direct participants, there are several instances where information is exchanged among participants utilizing the same HISP. But, what about those situations where the participants subscribe to services from different HISPs? An analogy is two email subscribers using services from two different email providers like Hotmail and Gmail. If two subscribers were both using Hotmail, a message could be routed internally by internal proprietary protocols to optimize system performance. However, a message addressed to a Gmail account from a Hotmail account needs to travel between the two providers over a standard communication protocol understood by both parties. In Direct terms, this common protocol between HISPs is called the backbone transport. The backbone transport is the protocol utilized for HISP-to-HISP communication.

In the early Direct workgroups, there was much debate regarding the underlying technology that would ultimately drive the information exchange. After small battle royale where four competing proposals went up against each other in a working code bake-off, the last man standing was SMTP with MIME attachments as described by RFC5322.

Why SMTP with MIME? For several reasons. First, Direct wanted to build on existing standards, and SMTP is a ubiquitous and mature standard for message transport. It is the transport of email, and there were roughly 300 billion messages exchanged per day in 2010 illustrating the scalability of SMTP.

An important attribute of the original Direct Project proposal was universal addressing. Addressing refers to the source and destination endpoints of a message and how they are named. Universal means that an endpoint name is unique across the entire namespace of a protocol. How does SMTP solve universal addressing? Do you have an email address? Then you have a universal address. Internet addresses as described in RFC5322 are globally unique endpoints. Generally, each Direct participant that subscribes to HISP services is assigned an email address. Message routing to an internet address over SMTP is already built into almost every SMTP server using DNS standards.

SMTP is also more or less agnostic to the content of the payload carried in the message. RFC5322 gives some structure and meaning to the payload, but is still flexible enough to allow almost any type of content to be packaged. This is an extremely import attribute of Direct, as it does not limit the type of content that can be exchanged from one participant to another. There are, of course, limitations regarding the type of applications that can be built on top of Direct. SMTP is not fit for purpose for every use case.

Finally, SMTP is a push protocol which removes the need for query/response. It is also an asynchronous protocol which adds complexity to ensuring quality of service. This means that there is not a guarantee that a message will be successfully delivered to its final destination after it is leaves the source endpoint. Additional work is currently being done to provide further guidance for HISPs' responsibilities in terms of quality of service. Some use cases utilizing Direct will absolutely require certain levels of message delivery assurance or negative acknowledgement.

The Direct Project does leave room for other protocols such as SOAP to be used as the backbone transport. This has both historical and forward looking implications and potentially requires more complex configuration and pre-negotiated protocol and address routing. The Direct Project, however, requires HISPs to support SMTP as a backbone transport protocol option to provide a common transport standard across all HISPs.

Message Gateway

The message gateway is not so much a concept as it is an implementation detail of the backbone transport. When a message is addressed to a recipient within the same HISP as the sender, the Direct Project does not specify how the HISP routes the message internally. However, if the sender and recipient are not within the same HISP, the message must be transported from the sender's HISP to the recipient's HISP. This is where the message gateway comes into play. The message gateway is the component inside the sender's HISP that is responsible for taking the messages and transporting it to the remote HISP. In the recipient's HISP, the message gateway is responsible for receiving the message from a remote HISP and handing it off to the appropriate internal components that will ultimately deliver the message to the final endpoint. In some deployments the gateway may also be the internal routing and delivery mechanism, but this is specific to the implementation of the HISP.

The message gateway is the outermost component of a HISP in terms of network topology and exchanges messages using SMTP directly over the internet. It is the point of entry and exit of a message to and from a HISP. Using best practices, the message gateway would be an enterprise class SMTP server such as Cisco IronPort. Open source SMTP servers such as Apache James or Courier are capable messaging gateways, but because the message gateway is exposed directly to the public internet, it is susceptible to all sorts of attacks. According to some estimates, roughly 90 percent of all email messages are considered spam. Although the security and trust components described in the next section will filter out spam and untrusted messages, it is much more efficient to use a good spam filter to remove unwanted messages at the HISP's point of entry.

In the next part of this series, I will breakdown the security and trust components which make up the heart of the Direct project.

Part two of this series covers security and trust, while part three touches on edge protocols, clients and policy.

Greg is a director and principal architect at Cerner. He’s responsible for the HISP architecture of the Cerner Direct solution and remains actively engaged in development/coding and mentoring new software engineers and upcoming architects. Also responsible for the Direct Project Java reference implementation architecture and a primary source contributor, Greg serves as co-chair for the Direct reference implementation workgroup and is a contributing member of ONC's Standards and Interoperability (S and I) Framework initiative and DirectTrust.org.