April 06 2012
The Direct Project: A modular view - part one
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
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:
care provider referring a patient to a specialist including summary care
of lab results to an ordering provider
sending health information to a patient
care provider sending a patient's immunization data to public health
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.
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:
transport and universal addressing
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.
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.
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.