Direct Communities
Contents
Table of Contents
Introductory Note
The objectives, charter, list of participants, several reference documents, and weekly meeting notes for the Direct Rules of the Road workgroup responsible for creating these wiki pages may be accessed here.
Summary
Direct Communities are real-world organizations or groups of organizations that (a) agree to abide by a set of policies, rules, and best practices, and; (b) have some mechanism (which may include self-attestation, formal accrediting or auditing procedures, or others) for enforcement of those policies. This page contains a list of communities at various stages of development; details on each can be found on the linked pages below.
The original work of the Direct Project was constrained to defining a technology solution to support directed exchange of health information between known participants. While the Direct Project posited potential policies as part of the requirements definition, it was understood that real-world implementations would require a set of concrete policy decisions and rules that would establish trust among parties who implement Direct exchange for various subscribers, e.g. for physicians, other providers, hospitals, and patients. For example, the Direct Project specifications require that each address be associated with one or more certificates and describes how those certificates are used to encrypt messages and validate message signatures. They do not, however, specify the conditions under which those certificates should be created, nor do they specify the conditions which would encourage other parties to trust the certificates. It is largely this latter specification that this workgroup has taken up as its core work.
One early point of consensus among this workgroup's members was an acknowledgment that a single set of policies and rules (or a single "trust circle") was unlikely to emerge immediately. While this was clearly desirable over time, members with experiences from states, HIE vendors, DURSA veterans, and other implementations of PKI were consistent on the reality of this point. Fortunately, the Direct technology was designed so that, with one technology implementation and one single Direct address, a Direct user might simply (with configuration) participate in multiple "trust circles," thus giving them the broadest universe of connectivity possible (more history on this in the Security & Trust Workgroup consensus overview page).
The division of the work of this workgroup into three Communities does not, therefore, represent any change to the fundamental specifications and protocols of the Direct Project. Rather, it represents the real world observation that different groups of Direct end-users may have need of different policies and rules that would facilitate trust within that community.
Note that providers and organizations can participate easily in multiple communities with each user having a single address. Multiple communities does not imply fragmentation of the address space. Enabling this was a fundamental design principle of the Direct technology specifications.
Active Communities
Direct Ecosystem Community
This community was formed to define a baseline set of policies that can facilitate broad exchange among a diverse set of participants, the majority of whom are covered entities or business associates of covered entities and therefore subject to HIPAA. The community is working to achieve responsible consensus quickly in support of imminent real-world deployments of Direct that serve this set of health care provider participants.
Direct Federal Community
Members of this community are able to exchange messages with Federal entities. The policies for this community will be those endorsed by ONC through the HITPC and Tiger Team. These requirements are evolving through committee discussions, hearings and research. They may ultimately be sufficiently compatible with those being developed in the Ecosystem Community that the two communities can be folded into one.
Direct Citizen Community
Members of this community include entities providing Direct addresses for citizens and providers/organizations that choose to exchange messages with them. The unique needs of citizen addresses requires a different approach to identity proofing and in many cases an asymmetric trust model (not all providers that send information to their patients want to receive messages from them).
Background
The Direct Project Overview document provides a good introduction to the purpose and model of Direct communication. As described in the overview, the logical role of a Direct Health Information Service Provider (HISP) can be filled by a variety of organizations including providers, payers, EHR vendors, PHR vendors, health information exchanges, and third-party commercial vendors. The Direct Project developed a set of specifications to enable a secure, scalable, standards-based mechanism for universal transport and addressing that every HISP must follow. The consensus obtained during this process is expressed in the Applicability Statement for Secure Health Transport and includes (but is not limited to) use of X.509 certificates, S/MIME, MDNs, RFC5322 payload formatting, email-like endpoint addresses, and an SMTP backbone protocol. Consensus was also achieved within the XDR and XDM for Direct Messaging specification for use of XD* metadata with XDR and XDM as well as conversion mechanisms for data traversing both XDR and SMTP.
All organizations and individuals wanting to securely communicate via the Direct Project protocols rely on underlying asymmetric key algorithms to enforce message privacy, authentication, integrity, and non-repudiation. While these principles form the backbone of trust on which a Direct public key infrastructure (PKI) is built, they must be accompanied by policies and procedures that (a) reliably bind an organization or individual identity to one or more X.509 digital certificates, (b) manage the associated private keys appropriately, and (c) ensure Protected Health Information (PHI) is handled in a manner conformant with HIPAA requirements regardless of whether entities are officially considered HIPAA covered entities.
Each Direct Community above defines a set of policies by which all community participants agree to abide. The end goal is to achieve community-wide secure “push” information exchange and interoperability within the confines of a PKI trust model and associated business processes and procedures.
Definitions
HIDP: A Health Identity Provider (HIDP) executes the roles of Registration Authority (RA) and Certificate Authority (CA) and ultimately is responsible for providing organizational and individual Direct certificates to verified organizations and individuals. As an RA, a HIDP collects information for the purpose of verifying the identity of an individual or organization and produces a certificate request which is a standard format for expressing information about an individual or organization. As a CA, a HIDP digitally signs certificate requests and issues X.509 digital certificates that tie a public key to attributes of its owner.
HISP: A Health Information Service Provider (HISP) is a role in a Direct message exchange that provides edge protocols, message formatting, security, and routing according to the Direct project specification. A HISP also provides truststore management tools and services for Direct users. The HISP role may be played by providers, payers, EHR vendors, PHR vendors, health information exchanges, and third-party entities.
Organizational Certificate: An organizational certificate is an X.509 certificate bound to the identity of an organization and not necessarily an individual. An Organizational Certificate is tied to a domain name by the presence of a DNS Subject Alternative Name extension that lists the domain name. See section 4.1.2 of the Applicability Statement. Organizational certificates may be associated with multiple Direct addresses within an organization.
Individual Certificate: An individual certificate is an X.509 certificate bound to the identity of an individual. An individual certificate is associated with exactly one Direct address which is listed in the email Subject Alternative Name extension (preferred) or in the EmailAddress attribute of the Subject Distinguished Name (legacy). See section 4.1.1 of the Applicability Statement.
Root Certificate: A root certificate is an X.509 certificate issued by a Root Certificate Authority and used to verify the digital signatures associated with all certificates issued by the HIDP. A root certificate is the top-most certificate of the tree structure of certificates, the private key of which is used to "sign" other certificates. A root certificate is a self-signed certificate that identifies the Root Certificate Authority. A root certificate has the X.509 CA basic constraint extension set to "true."
The Direct PKI Model of Trust
A HIDP issues X.509 organizational and/or individual certificates. The process of issuance primarily involves creating the necessary metadata in the correct format and digitally signing the resulting data. The signature on a certificate is validated by a relying party (e.g., a Direct user) using the public key associated with the issuing HIDP's root certificate.
For example, a Direct user Alice may choose to trust another Direct user Bob by placing a certificate in Alice’s truststore that allows Alice to validate Bob’s certificate. The certificate placed in Alice’s truststore may be the HIDP Root Certificate that issued Bob’s certificate, Bob’s organizational certificate, or Bob’s individual certificate. Bob’s direct address will be tied to an organizational certificate, individual certificate, or possibly both.
By placing Bob’s organizational or individual certificate in her truststore, Alice is stating that she will trust messages signed by Bob’s associated private key without necessarily trusting all certificates issued by Bob’s HIDP. This is a fine-grained trust configuration.
By placing the HIDP root certificate that issued Bob’s certificate in her trust store, Alice is stating that she will trust all certificates issued by Bob’s HIDP. This is a coarse-grained trust configuration.
Alice’s truststore may include both coarse-grained and fine-grained elements.
Trust Beyond the Direct PKI Model
A given entity may choose to play both the roles of HIDP and HISP or it may choose to play only one. The Direct PKI Model of Trust provides the building blocks for a comprehensive set of policies that define the rules of the road for a Direct community.
