DirectTrust 101A brief introduction to Direct, Direct Exchange, and DirectTrust, intended for both technical and non-technical audiences.
What is DirectTrust and What Does DirectTrust Do?
The most important thing to know about Direct health information exchange is that it is just like email, but with an added layer of security and trust-in-identity operating behind the scenes. This makes Direct exchange of messages and attachments suitable for electronic sharing of personal health information (PHI), which HIPAA requires must remain private and confidential at all times. Due to these capabilities and characteristics - ease of use, security of electronic transmission, low cost of operations - Direct exchange will soon replace insecure fax, courier, and mail for many kinds of health care transactions.
DirectTrust is a non-profit health care industry alliance that has established and maintains rules, standards, and policies associated with the operation of the security and trust-in-identity layer for Direct exchange. Taken together, these make up a Security and Trust Framework that supports both Direct exchange implementers and users, in the following ways.
- DirectTrust utilizes its Security and Trust Framework as the basis for a voluntary accreditation and audit program for Direct implementers/service providers, including for Health Internet Service Providers (HISPs), Certificate Authorities (CAs), and Registration Authorities (RAs). Publication of accreditation statusallows relying parties to know the security policies and identity best practices and standards for business behaviors for which accredited entities are endorsed and accountable.
- In addition, DirectTrust distributes what are known as “trust anchor” digital certificatesfrom accredited DirectTrust service providers (HISPs), so that Direct Secure Messages can be exchanged across different Direct implementations, at scale and without the need for complex one-off negotiations between relying parties. Instead of having to exchange trust anchors with each other one at a time, all HISPs can access the trust anchors from a single authoritative, centralized source.
At the end of March 2013, the Office of the National Coordinator for Health IT (ONC) awarded DirectTrust a cooperative agreement grant as part of the Exemplar HIE Governance Entity Program. Further, a communication from ONC on May 24, 2013 stated in part: “We encourage HISPs to get accredited by DirectTrust and add their anchor certificates to its trust bundle to ensure the providers using their services are able to exchange information across vendor and organizational boundaries.
Widespread participation in DirectTrust by entities that offer Direct services or provide supporting services will enable providers to easily and securely exchange patient health information using Direct, irrespective of organizational and vendor boundaries, to meet Stage 2 Meaningful Use exchange requirements and overall care coordination needs.”
In brief, then, DirectTrust is a federally recognized, non-profit policy and governance body that makes it possible for Direct exchange to operate smoothly and reliably, giving Direct users much-needed confidence in their exchange partners’ privacy and security practices.
Why is Direct important?
As background, consider that even though more and more health care providers and hospitals are adopting EHRs, none of these software applications is inherently capable of “talking with” other EHRs; that is, they are not “interoperable” with one another. For example, prior to the development of Direct exchange, users of aneClinicalWorks EHR could not securely exchange health information with users of aCerner EHR system, or any other vendor’s system for that matter. Prior to Direct, each EHR system was a “silo” of data and information, separate and disconnected from other sources of patient information, leaving providers to rely on fax, e-fax, and mail for most communications.
Why was it important to fix this problem? Because lack of interoperability between siloed EHRs inhibits the ability of doctors, nurses, and other health care professionals to coordinate care in real time across organizational and IT system boundaries. In particular, during transitions of care — for example when a patient leaves a hospital using one EHR and care continues in the outpatient setting where another EHR is in use — vitally important health information often doesn’t follow the patient as it should, which then can lead to duplication of testing, missed appointments, mistakes in medications, and sometimes even unnecessary re-hospitalizations. And, needless to say, clnicians who find it difficult to share EHR data among themselves find it even more difficult to transmit or share this information with patients and consumers, who then miss out on the opportunity to be informed and fully engaged in their care decisions.
The developers of Direct exchange saw an opportunity to redress this lack of interoperability and to promote health information exchange in general by specifying a simple and standards-based way for people to send and receive authenticated and encrypted health information over the Internet, regardless of location or EHR system in use by exchanging parties. The basic notion was that exchange of information between point A and point B, if based on known standards such as SMTP — the world-wide protocol for email — and made secure would overcome the siloing effect of the current, proprietary EHR technologies, while at the same time allow for consumers and patients to participate in information sharing via the use of web-based email applications.
With Direct exchange in place, the data sharing needs of care coordination, transitions of care, and patient engagement can now be met at low cost, and with computer software familiar to anyone who has ever used email. For example, Direct messaging is now being used in several communities to alert primary care providers when their patients are discharged from the hospital, and there are early indications that these alerts are lowering re-admission rates. (See page 12 of the Beacon National Learning Guide for a case study using Direct exchange.)
Who developed Direct?
When used by providers and hospitals to transport and share qualifying clinical content, the combination of that content and Direct exchange is now an integral component of Stage 2 Meaningful Use objectives and measures that eligible providers must meet to receive payments towards their EHRs and to avoid penalties in their Medicare payment schedule. For example, a primary care physician who is referring a patient to a specialist and uses Direct exchange to provide a Clinical Summary of that patient to the specialist, will be able to attest to having met one of the Stage 2 objectives for transitions of care.
Stage 2 Meaningful Use, which began in early 2014, also requires that providers enable patients to “view, download, and transmit to a third party of their choice” their clinical information in electronic format; the transmit function may be satisfied via use of Direct exchange, and EHRs or their patient portals will need to be certified to offer this transmittal via Direct.
There are numerous sources of additional information about the Direct Project. A good starting place for a high-level overview is an article published in Health Affairs on March 5, 2012, entitled “From the Office of the National Coordinator: The Strategy for Advancing the Exchange of Health Information.” (Subscription may be needed). The Direct Project maintains a wiki. The most comprehensive single overview of the Direct Project is The Direct Project Overview from February 2010. There is a Direct Project website. In addition, the National eHealth Coalition (NeHC) maintains a library of video courses on theDirect Project and Directed exchange. If you want the technical protocols and specifications for Direct, the definitive technical document for Direct is the Applicability Statement for Secure Health Transport of the Direct Project.
How does Direct work?
Direct messages can have any type of file attachment, and both message and attachments are encrypted along the entire route from Sender to Receiver, to protect the privacy of the content.
Direct users need to subscribe to Direct exchange through an entity acting as a HISP. However, the type of organization that acts as a HISP may vary. For example, some EHR vendors offer HISP services directly to their customers, while other EHRs have partnered with stand-alone HISPs to offer Direct. A large health care provider or hospital system may choose to be its own independent HISP, working with several EHRs and patient portals. There are Personal Health Records (PHRs) that provide HISP account and addressing services for patients and consumers as part of their offerings. This role of HISP is fairly new to the market, therefore it is understandable that several configurations for the delivery of Direct exchange services are evolving.
The Sending and Receiving Systems in the illustration might be an EHR, or a web portal, or even a smartphone. Any device capable of sending an encrypted message (in one of several communication protocols) to the addressee’s HISP could be an end-point for sending and receiving a Direct message, including medical devices used by patients at home. Any Direct addressee/end-point will thus be capable of connecting via Direct with any other addressee end-point, whether within the single domain of a HISP, or across the domains of two different HISPs.
Are you beginning to get a sense of the simplicity, but also the versatility and usefulness of Direct exchange?
If you are a provider, health professional, or patient who is using Direct exchange, you really don’t need to know much more about Direct than what is captured here and in the illustration above. However, it is VERY IMPORTANT that the Sending System you choose to use for Direct exchange is certified, and that the HISP you choose to use in combination with that Sending System is accredited by DirectTrust.
Certification of the product you use to send and receive Direct email messages brings assurance that the Direct protocols and specifications are being deployed properly. Certification is a test of the software’s technical capabilities according to the Direct standard.
Accreditation of the HISP you subscribe to brings assurance that the privacy, security, and trust-in-identity policies and practices of that HISP have been approved by an accrediting body for the industry, and that these standards are set at a high enough level to protect you from risk and liability associated with health information exchange over the Internet.
Why is accreditation of HISPs, CAs, and RAs necessary?
Accreditation and audit provide assurance throughout the Direct exchange community of adherence to policies, standards, and best practices by identifying accredited entities and allowing them to display the DirectTrust seal of approval. Further, accreditation saves time and money by obviating the need for Direct implementers and trusted agents to negotiate with one another about privacy, security, and trust-in-identity at each exchange episode.
However, to answer the question more comprehensively, we must first ask a different but closely related question: why is trust between sender and receiver (and their respective HISPs) such an important requirement for Direct exchange? Accreditation is a means to gain trusted status, and then to signal to others that you are trustworthy as a Direct exchange partner. (In the actual case, it is the trusted agents of the senders and receivers, the HISP, CAs, and RAs, that are being accredited.) Why, precisely, is it important that Direct exchange senders and receivers trust one another, and what, exactly, are they trusting each other to do or not do? The answer, in a couple of words: management of risk.
The concept of using an Internet transport mechanism like Direct email for the exchange of health information should make people worry about two specific risks that are inherent to information flow over an open network, which the Internet most certainly is, and which need to be managed. The first is the risk that the content of the message and/or the attachments may be exposed, and thus fall into the wrong person’s hands. This is called a breach of privacy, and the threat of this kind of exposure is greatly increased when personal health information (PHI) is handled in an insecure manner, or when security measures are in place but they are lax and prone to error. Encryption of data in transit from point A to point B is one way to address the risk of breaching privacy, but there are a number of different ways to perform encryption that are less likely to be decrypted by an unauthorized party.
The second specific risk that needs to be considered during the exchange of PHI is identity spoofing, which can lead to identity theft. There is an old cartoon joke that has one pooch telling another “On the Internet, nobody knows you’re a dog.” In fact, much of the time that we use the Internet we can’t be certain that the parties we’re communicating with in cyberspace are actually who they are in the real world. They might, in fact, be dogs. Most of the time our email partners are who they say they are, and we simply trust that the system will not let us down.
However, exploiting this trust is fairly easy to do: all of us are familiar with “phishing,” which is the attempt by someone (usually a bad guy) to impersonate a person or business via email or the web, and thus gain access to important identifying information such as IDs and passwords, social security numbers, and so on. If that information is accessible, it can then be used to reach resources like bank accounts or e-commerce websites, and real economic and emotional harm can be the result of what has become known as Internet identity theft. The deployment and use of strong online identity credentials, such as digital certificates, is one way to mitigate the risk of identity spoofing and theft.
To manage and mitigate these risks when electronically transmitting patients’ personal health information is not only critically important, it is the law. HIPAA specifically requires providers, health plans, pharmacies, and many other health care entities, as well as their business associates who handle PHI on their behalf (e.g. EHRs, HISPs, other health IT providers), to protect the privacy of PHI and to practice security measures adequate to mitigate these types of risks. Failure to do so can, and will bring heavy fines and even criminal penalties to doctors and hospitals if breaches occur that put patients’ identifiable health information at risk of exposure, even if unintentional or caused by accident.
Therefore, health care providers and others who use Direct exchange really have no choice but to take whatever measures are necessary to be assured themselves, and to assure others with whom they share data, that adequate security and trust-in-identity policies and practices are set at a high enough bar and are in place at all times.
In practice, this means that Direct exchange senders and receivers must trust one another, and their trusted agents and business associates such as HISPs, upon whom they rely for exchange processes, to have in place a set of standards, policies, and best practices that provide the minimum assurances needed for the exchanges to go forward, at low risk. Doctor A using HISP A who wishes to exchange health information for a patient who she is treating in common with Doctor B using HISP B, needs to trust not only that her own trusted agent, HISP A, is practicing strong security controls, but also that Doctor B’s HISP, HISP B, is practicing similar strong security controls. She and her practice are potentially liable for anything that could cause a breach of privacy in the exchange.
Given that HISP B could be any one of many such service providers around the country (there are, in fact, HISPs C,D, E….Z), and that HISP B is not directly under the control of Doctor A (is not even a business associate of Doctor A), how can she trust HISP B to be in compliance with strong security and identity controls? There are a couple of ways that such trust might be established.
- HISP A could negotiate a contract with HISP B, laying out the mutually agreed upon security and trust-in-identity policies and practices they both will follow and uphold. We can expect such a contract to be complex and fairly lengthy, both because the issues are complex and because not everyone’s threat assessment will be the same, leading to disagreements as to the level of security and identity controls that need to be in place. Such contracts might take weeks or months to hammer out.
- HISP A and B could agree that instead of using a single contract between them, to undergo voluntary third-party accreditation and audit; essentially a test that, if successfully passed, signals both are meeting the same levels of privacy, security and identity controls. Accreditation would be more acceptable to HISP A and B (and other HISPs, too) if they are given the opportunity to help develop the accreditation criteria, provide ongoing feedback to the process, and if they both feel that the criteria are mutually agreed to and have been arrived at through an open, neutral, and transparent process.
The DirectTrust community members, with support from ONC, favor the second alternative, that of accreditation and audit against a set of policies and standards for security and trust-in-identity, because it avoids the complexity, variability, and cost of individual contracts. Creating a recognizable “seal of approval” also reduces the need for Direct implementers to engage in one-to-one contractual arrangements before allowing information to flow between each other’s systems.
DirectTrust’s accreditation process also gives Direct implementers a simple way of establishing scalable technical trust via electronic trust bundle exchange. A trust bundle is a collection of anchor certificates from health information service providers (HISPs) that comply with a baseline set of common policies and practices. This eliminates the need for participating HISPs to manually exchange and maintain trust anchors with each other.
This complement of activities outlined above not only helps to create confidence among healthcare providers using Direct exchange, it saves implementers time and money by avoiding one off contracts and mechanisms for sharing trust anchors.