Direct Project, HISPs, and the Basics

The Need for Simple Information Exchange?

What is information exchange? Oversimplified and in the proper context, it 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. Although the definition of an HIO is not overly important for the scope of this text, be aware that there are some definitions and standards that explicitly define exchange outside the boundaries of an HIO. The history of information exchange is long, complex, and outside the scope of this blog. However, several initiatives and standards have emerged over the years to address the use cases of information exchange.?

This slide deck is a presentation of a blog entry by Wes Rishel detailing some of his 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 of a "query-response" infrastructure, which had been historically complex, and create 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.?

A trivial use case where Simple Interop could immediately provide value is the electronic sending of documents over telephone lines. Tech elders would recognize this as faxing. Taking another technological step backwards, some organizations still rely on snail mail for information exchange. Both methods are used in several use cases in the exchange of health care information but take advantage of the same underlying technology. Some of these use cases include:?

• 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?

What is the Direct Project (shortened to Direct throughout this text)? Simply put, it is a set of specifications and standards. The Direct Project 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 that were 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 which is defined in a document called the Applicability Statement for Secure Health Transport.?

The Direct Project 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:?

1. Backbone transport and universal addressing

2. Messaging gateway

3. Security and trust

4. Edge protocols?

5. 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 Provider (HISP)?

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 the Direct Project, 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 the Direct Project, this mysterious entity that powers data exchange is called a Health Information Service Provider or HISP.?

A HISP is a logical concept that encompasses certain services that are required for Direct Project data exchange such as the management of trust between senders and receivers. 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 or 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 Project concepts such as universal addresses, certificate management, security, trust management, and information transport.?

Backbone Transport?

What is a backbone transport? In the previous section, I defined a HISP and gave a brief description of how Direct participants utilize HISP services to exchange data. Because a HISP can be hosting 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 HIPSs is called the backbone transport. The backbone transport is the protocol utilized for HISP to HISP communication.?

So what protocol does Direct use as its backbone transport? In the early workgroups of the Direct Project, there was much debate regarding the underlying technology that would ultimately drive the information exchange. It took a small battle royale of four competing proposals that went up against each other in a real working code bake-off, but when all the dust settled, the last man standing was SMTP with MIME attachments as described by RFC5322.?

Why SMTP with MIME? For several reasons. First, the Direct Project 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 that SMTP is a proven scalable solution.?

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 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. Quality of service is beyond the scope of this text but know that it is partially addressed in the applicability statement. 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% 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.?

Security and Trust?

The Direct Project definition specifies sending authenticated messages securely to trusted recipients. What does that mean? Let's break it down into parts.?

Message Security?

First, messages must be delivered securely. That is quite a general and ambiguous statement. In Direct, a secure message is one that has been encrypted and signed. Because Direct uses MIME messages as its payload over SMTP, it needs a way to secure the message but remain in compliance with MIME standards. Fortunately, there is such an extension to MIME called secure MIME or S/MIME and is defined by RFC5751. S/MIME has attributes that cover both security and message authenticity, but let's focus first on security.?

The Direct specification states that all messages on the backbone protocol have a MIME content type of application/pkcs7-mime: the content type of an encrypted S/MIME message. Direct implicitly defines a component called the security and trust agent that is responsible for encrypting and decrypting all outgoing and incoming messages respectively using PKI and X509 certificates. PKI stands for public key infrastructure, and itself has several books published on the topic. A deep dive into PKI is beyond the scope of this text, but one important concept is X509 certificates. I will dive deeper into X509 certificates in the certificate management section, but for the purpose of S/MIME know that certificates contain the keys that are used to encrypt and decrypt messages.?

Every endpoint in Direct is associated with one or more X509 certificates. The relationship between the endpoints and how they are discovered will be covered in subsequent sections. When a message is addressed to a recipient, the message is encrypted using the recipient's public key using S/MIME standards. This is an oversimplification of the process, but the result is an S/MIME encrypted message envelope that internally contains the original message. The encrypted payload is then sent to the receiving HISP using SMTP over public networks. When the recipient's HISP receives the message, the recipient's certificate is obtained along with the corresponding private key. The message is then decrypted, and the original message is extracted. PKI ensures that only the recipient's private key can decrypt the message.?

So why PKI and S/MIME instead of other cryptography technologies such as TLS over SMTP? The most notable reason is that although SMTP defines a secure version of the protocol, most public SMTP servers do not use or at least do not require it. It's all about universal standards and ubiquitous support. Almost every public SMPT server supports transport over a non-encrypted channel. Because the line is unencrypted, the message payload itself must be encrypted to protect against eavesdropping and ensure message integrity.?

Message Authentication?

Direct does not implement authentication in the typical sense of using a username and password. Instead, it refers to the authenticity of the message, meaning the source address of the message is the actual source of the message. Huh? When a message is received by a HISP from another HISP, it looks at certain?headers in the SMTP envelope to determine the source address of the message. There are exploits where a malicious email client or server can spoof or pretend to be a fictitious message source. Message authenticity gives a level of assurance that the message is indeed from the person or system that created the message. Message authenticity is another feature provided by S/MIME in a concept called a message signature.?

The message signature is a blob of bits that can validate the authenticity of the message. Without going too deep into the process, the message signature is created by generating a cryptographic hash or digest of the original message. The digest is just a fixed length sequence of numbers or combination of numbers and letters that, in theory, uniquely represents the message. Because the digest is a function of the message content, each message could generate a unique digest. Saying the digest will be unique for every message is not entirely true, but practically the probability of two different messages creating the same digest (called collision) is relatively low. The digest is then encrypted with the sender's private key. When the message is received by the recipient's HISP, the security and trust agent obtains the X509 certificate associated to the sender and decrypts the digest in the message signature. Only the sender's public key will be able to decrypt the digest. A digest is then taken of the original message and compared against the decrypted digest. If the digests match, then the message is declared authentic.?

So message signatures provide two functions:?

1. They ensure the message was not tampered with by using a comparison of digests.

2. They ensure the message source is authentic using the public key of the sender's X509 certificate.?

Certificate Discovery?

I have made several references to certificates being "discovered" for encryption, decryption, and creating a signature. PKI can be difficult to implement, and certificate discovery is just one small piece of the puzzle. There are two use cases of certificate discovery in Direct: private and public discovery. Private discovery refers to accessing a certificate along with its private key and is always handled within a HISP. It is up to the HISP to implement proper protection of private keys and the methods to access them. The Direct Project implements a few certificate resolvers for discovering private certificates, but they do not meet policy requirements of legitimate PKIs. More on policy later.?

Public discovery refers to finding certificates that are not managed by the HISP and is a much more interesting problem. Public discovery has three problems to overcome: where is a certificate stored, what protocol to use, and how to uniquely identify the certificate within a query. Additionally, a universal discovery method is desirable to reduce variance and ensure interoperability. Because the Direct Project wanted to use existing and ubiquitous standards, DNS using CERT type records was selected as the preferred method. LDAP was added later as a secondary method and standardized by the S&I Framework initiative. HISPs can host either a DNS or LDAP implementation to publish Direct certificates publicly.?

The details of the discovery algorithms for both DNS and LDAP (and controversy surrounding them) will not be outlined here, but the Direct Project does provide open source libraries that support both methods.?

Trust?

Arguably the most important aspect of the security and trust specification is the trust model. The encryption and message signature algorithms ensure that a message is securely transported from one location to another without being compromised or tampered with, but what value is a message if you do not trust its contents? In theory, anyone can set up a HISP, create certificates, and claim to have some type of authoritative credentials such as being a covered entity (HIPPA lingo). A Direct participant may be able to irrefutably attest to their identity assigned to them by their HISP using a certificate, but how does a receiving participant know that they can trust the content of the dialog? In other words, if I receive a message from Dr. Bob, how do I know the public certificate presented to me actually represents Dr. Bob. The attributes in the certificate say it's Dr. Bob, but is the HISP that gave Dr. Bob that certificate actually trustworthy? What if Dr. Bob is really the sinister Archibald Bareasaol who stood up his own HISP to spoof the legitimate (but obviously fictitious) healthcare organization of Our Lady of the L4 Credential??

The security and trust model allows a HISP to "filter" and accept messages only from other HISPs that they deem trustworthy. Transitively, a HISP should only allow the creation of addresses for participants that they deem trustworthy. This leads into the subject of identity proofing and certificate policies which is outside the scope of the trust model as defined by the applicability statement, but there are efforts in the Direct community that are solely focused on this topic. However, as a rule of thumb, only HISPs that follow and prove to abide by good certificate practices and identity proofing procedures should be deemed trustworthy.?

Trust is not an absolute indicator of truth in terms of content but subjective only in how much a recipient wants to trust the sender. In the context of health care data, trust in content can result in a life-changing decision, and in the extreme, a case of life or death.?

The security and trust model provides a great deal of flexibility in determining trust relationships between HISPs and even individual users. Because messages are signed using the sender's X509 certificate, PKI algorithms "filter" messages based on entities called trust anchors. Every X509 certificate is issued from an entity called a certificate authority, and a certificate authority can be used to validate the authenticity of the issuer of an X509 certificate. In the most simple case, a certificate authority (CA) is a trust anchor. If a HISP trusts a particular trust anchor, then all certificates created by that anchor are considered to be trusted. A HISP's filter may become more granular from this point using whitelists and blacklists.?

Depending on the PKI implementation of a HISP, a trust anchor may be assigned to represent an entire HISP, but generally a trust anchor is created per email domain that a HISP hosts. Technically, setting up a trust relationship between HISPs is as simple as the HISPs exchanging trust anchors in a secure manner and adding the anchors to their trust stores. A trust store is just a set of trust anchors that a HISP has deemed trustworthy. Applying this to messages, any message signed with a certificate that is issued by a trusted anchor is deemed trusted.?

In practice, the process of establishing trust between HISPs is much more complex and requires due diligence in determining if a HISP is legitimate and is following required policies and procedures.?

Putting It Together?

A little order is now called for. Direct uses the following simplified pseudo algorithm when sending messages:?

1. The message is validated for all proper MIME content
2. The sender's private key is discovered, and a message signature is generated
3. The recipient's or recipients' certificates are discovered and the message + signature is encrypted into an S/MIME envelope
4. The encrypted message is sent to the recipients' HISP(s) using the message gateway?

Conversely, Direct uses the following simplified pseudo algorithm when receiving messages:?

1. The encrypted message is received by the message gateway and handed off to the security and trust agent
2. The recipient's or recipients' private keys are discovered, and the message is decrypted
3. The sender's certificate is discovered, and the message signature is verified
4. The sender's certificate is checked against the trust store to ensure the sender is from a trusted HISP?

A failure in any of the steps results in the message being discarded, and an appropriate action is taken by the sending or receiving HISP.?

Edge Protocols and Source/Destination Clients?

Now that you know how messages are sent from HISP to HISP, how do they get to the final destination? The Direct Project does not specify a set of applications or workflows for reading or processing the contents of messages. They left that to the genius of developers to innovate uses of Direct. These applications are called source and destination clients. They are the applications that either generate and/or receive messages. An example client is an email application such as Microsoft Outlook or Mozilla Thunderbird. These applications can both create and receive messages for simple correspondence workflows. Another example may be an electronic health system that generates a structured CCD document on patient discharge and sends it to the patients or another physician or practice.?

That's right; Direct is not just email! In fact I would be so bold to say it is not email at all; it is just a set of standards that happens to use the same backbone transport as email. Email is just one of the many use cases of Direct.?

So how do the messages get to and from the HISP and to and from the destinations and source clients? They use a transport called an edge protocol. An edge protocol is the transport protocol used to get a message from a source client to the HISP. The converse is true for destination clients. Direct does not specify any edge protocols with the exception of SOAP for XD messages, but XD is out of scope for this text. The edge protocols offered by a HISP are solely at the discretion of the HISP. They may be standard protocols such as SMTP or IMAP used by almost every email client, or they may offer proprietary APIs using technologies such as REST, SOAP, or JMS. The purpose of allowing additional edge protocols is to support and encourage innovation and not make the edge be a limiting factor of innovation. Some HISPs may not offer any edge protocols as they may prefer to only offer their own Direct based applications. An example could be a HISP that only offers a web-mail type inbox.?

Policy, Procedure, and Governance - Oh My?

In my own opinion, Direct is 30% technical and 70% policy driven. The technical specifications and subsequent 1.0 release of the Direct reference implementations took less than a year to produce from start to finish. The policy discussions are still ongoing. The reference implementation is an open source and pre-assembled implementation of the Direct Project specifications. An implementation exists in both the .Net and Java languages and can be downloaded freely from a handful of websites. A subproject of Direct called Bare Metal contains a set of instructions on procuring the reference implementation and standing up a reference HISP from scratch using only the reference implementation assemblies.?

Well, that sounds easy; it sort of is. Well, then I'm going to standup a HISP using Bare Metal and run a business out of my garage; not so likely. Why not? First, because nobody is going to trust your HISP. Second, the reference implementation and Bare Metal do not meet policies requirements in a number of areas. Policy and governance are at the heart of ongoing Direct discussion and development. The list of policies and the agencies that developing standards and governance is beyond the scope of this text, but the most notable polices are:?

Identity Proofing and Vetting Certificate Policy and Management?

Identify Proofing?

Like so many other topics in Direct, identity proofing concepts and procedures could make up an entire book. Grossly over-simplified, identity proofing is the process of assuring that an entity really is what it says it is. Entire workgroups are dedicated solely to the practice and policies of identity proofing, and adherence to these policies is a requirement of a HISP.?

In Direct there are two types of entities that are identity proofed: individual users and organizations. In the case of users, a certificate is issued to each email address. For organizations a single certificate is issued for an entire institution or larger entity. In the case of organizational certificates, they are generally issued at the email domain level, but that is not always the case. Either way, only the organization is identity proofed for the purpose of certificate issuance, and the organization is responsible and liable for the vetting of each email address that is issued.?

Certificate Policy?

Every endpoint in Direct has an X509 certificate associated with it. A certificate is an electronic type of credential, meaning it can be used to unambiguously?identify an entity within a certain level of assurance. Level of assurance describes the policies and procedures used to identity proof the entity. The higher the level of assurance, the higher the level of proof is needed to validate the identity of the entity. In X509 certificates, levels of assurance are asserted by the existence of an attribute called a certificate policy. There are different types of certificate policies, and coverage of the different types and how they map to levels of assurance is out of scope. However, each certificate policy is uniquely identified by an object identifier (OID). OIDs are another topic out of scope, however, know that they are a series of numbers organized in an hierarchical format to uniquely identify a concept.?

Another type of policy attribute is a certificate practice statement (CPS). A certificate practice statement is a document that outlines the procedures a certificate authority adheres to when creating, revoking, renewing, and validating certificates. It also outlines technical and management procedures of the certificate authority's lifecycle. This may include how the authority protects its private keys, performs backups, audits access to private keys, and possibly how entities are validated before issuing certificates. The CPS can be complimentary to a level of assurance policy, and together they give legitimacy to the certificate authority. Implementing procedures and polices set forth by a certificate policy or a CPS is not free. In fact, entire business models have been established around certificate policies. A legitimate HISP should only issue certificates from an authority that has an established certificate policy and is prepared to attest to following the policies set forth by their CPS.?

Certificate Management?

Certificate management refers to the policy and procedures used to manage the lifecycle of a certificate. These include issuance, revocation, renewal, and rekeying. It can also refer to the procedures used to protect the integrity of the PKI. This mainly covers protecting private keys, backing up keys, and auditing access to keys. Many of these procedures are outlined in a CPS and handled by the certificate authority. In the case of HISPs, issued certificates and their keys are held by the HISP; not the actual entities. This a slightly different model from most PKIs where the entities hold their own certificates and private keys. Because the HISP is the steward of the keys, it must take proper care in managing and protecting keys from unauthorized access or malicious attacks.?

Governance?

At the time of writing, governance is still being hashed out. There are different organizations developing policies for specific communities that Direct users will participate in. I could make fairly intelligent guesses as to which organizations will have governance over what communities, but it's premature to make any type of authoritative statement, and I will leave it at that.?

Summary?

The Direct Project addresses use cases for the simple exchange of health information. Direct Project services are hosted by entities called HISPs which implement the technical infrastructure of Direct. The Direct Projet uses SMTP as its backbone protocol and uses S/MIME and PKI for securing, authenticating, and trusting messages.?

The Direct Project offers a reference implementation of its specification, and the Bare Metal project provides a pre-assembled deployment of Direct that anyone can freely download and deploy. However, because the Direct Project is more about policy than technical implementation, a legitimate HISP must make investments to implement proper procedures and adhere to policies being developed by various governance organizations.?