by Lisa Nelson, Chief Technical Officer
If you don’t know the difference between an organization-level and a personnel-level Direct address, chances are your organization hasn’t implemented Direct Secure Messaging (Direct) to its full potential. When it comes to reducing administrative burden and leveraging interoperability, organization-level addresses are the MUST HAVE capability for systems that integrate Direct services.
It All Starts with Trust
Trust Frameworks play a crucial role in enabling secure communication between organizations by providing a shared foundation of standards and requirements. When all participants agree to the same rules, there’s no need for one-off legal contracts or custom agreements between each pair of organizations. This streamlined approach is often called scalable trust, because every new participant doesn’t just add a single connection, but unlocks access to an entire network. The result is exponential growth in trusted data exchange, rather than the slower, one-to-one connections of traditional models. Trust-in-identity is at the core of every Direct address. The DirectTrust network, built with privacy and security in mind, requires identity-proofing for entities that want to engage in health information exchange. The entity may be an organization (with its associated personnel), or it can be an individual patient or patient’s family member or caregiver.
About the DirectTrust Certificate Policy
DirectTrust’s Certificate Policy (CP), another component of the Trust Framework, is a formal document that defines the rules, requirements, and practices for issuing, managing, and using digital certificates used to enable secure healthcare communication via Direct.
The CP is a detailed specification that defines assurance levels, identity-proofing requirements, and certificate lifecycle rules. It specifies the intended uses for certificates and identifies the roles (e.g., Certificate Authorities (CAs), Registration Authorities (RAs), Trust Agents, Health Information Service Providers (HISPs), Subscribers, etc.) and responsibilities of different actors in the DirectTrust Trust Framework to make Direct Secure Messaging come to life. The CP ensures all participants follow uniform security and interoperability standards.
Domain-Bound Versus Address-Bound Certificates
The CP establishes rules that permit X.509 certificates to be created for organizational entities by identity-proofing personnel who are empowered to represent the organization. It also establishes rules that permit X.509 certificates to be created for individual entities by identity proofing the individual themself.
The X.509 certificates carry information about the associated entity (Subscriber), the type of entity, the level of identity assurance used in the identity-proofing process, and other assertions about conformance with various certificate policies. The certificates also include information about the CA who issued the certificate, the certificate’s expiration date, its own identification serial number, and where to look to determine if the certificate has been revoked.
Entity Types Associated with Direct X.509 Certificates
| Organizational Entity Types | Individual Entity Types |
| Certified Entity DirectTrust CE Business Associate DirectTrust BA Healthcare Entity DirectTrust HE DirectTrust Non-Declared* |
Individual DirectTrust Patient |
*For an organization that is not a Certified Entity or Business Associate under HIPAA as defined in HIPAA at 45 CFR 160.103 and is not a Healthcare Entity that is involved in healthcare and has agreed to protect private and confidential patient information consistent with the requirements of HIPAA.
Domain-bound certificates bind an entity’s identity to a domain (what comes to the right of the @ in a Direct address). Address-bound Certificates bind an entity’s identity to an address (a fully formed [email protected] where xxx is the unique part of the address and yyyy.zzz is the domain.)
The difference between a domain-bound certificate and an address-bound certificate in the context of the DirectTrust Trust Framework and Direct Secure Messaging comes down to which part of the address associates to the certificate.
DirectTrust allows both options to be used to accommodate the variety of scenarios that exist in the healthcare ecosystem for information exchange between organizations, their personnel, and patients and their caregivers.
How Direct Secure Messaging Works
It’s easy: A Direct address is used to send a message to another Direct address. The entity associated with the sending Direct address is responsible for the information being sent. The entity associated with the receiving Direct address is responsible for processing the information being received. The rules are simple, the responsibilities are clear, and the payload of the message can be anything it needs to be.
A system or application, such as an EHR, PHR, Public Health platform, EMS solution, etc. (often called an edge system), integrates Direct Secure Messaging services into its core functionality to enable secure communication as a Message Sender or Message Receiver. The edge system enables access controls to be managed so that an organization using Direct services can control which users have access to which Direct addresses.
The DirectTrust Trust Framework requires that all users of Direct services are identity-proofed. This requirement is placed on all accredited RAs and may be delegated to Trust Agents. Each distinct legal entity using Direct services must have its own certificate which is then bound to the Direct address domain or to an individual address. Thus, the identity of the sending and receiving entity can be discovered through the certificate associated with the Direct address involved in the messaging transaction as sender or receiver. For organizational entities, personnel accessing Direct services can be tracked through the audit logs of the system which offers Direct services.
Organization-level Versus Personnel-Level Direct Addresses
In the context of Direct services, a Direct address is also considered an endpoint. An endpoint is a network-accessible location (usually identified by a URL or address) that serves as the interface for communication between systems, applications, or devices. In the DirectTrust Aggregated Directory, each endpoint can include an associated endpoint use case which tells the information exchange purpose supported by the endpoint.
When Direct services are integrated into an edge system, access control policies in that system are used to control access to Direct services. When the edge system limits the use of a Direct endpoint to a specific user, this is called a personnel-level address. For a personnel-level address, the endpoint use case is usually “individual-practitioner.”
When the edge system enables the use of a Direct address by one or more users responsible for processing information associated with an organizationally-focused use case such as processing referrals, receiving notifications, or handling care coordination efforts, that type of Direct address is called an organization-level address. The endpoint use case might be “transfer-transition-of-care,” “referrals-360x,” or “adt-notification.” DirectTrust maintains a codeSystem and valueSet of established endpoint use case codes called ServDescVS.
To facilitate effective search capabilities, the DirectTrust Aggregated Directory handles organizational-level Direct address endpoints differently than personnel-level Direct address endpoints. Organizational-level endpoints are findable through a “yellow pages” view which is facilitated by searching with information about the organization. Individual-level endpoints are findable through a “white pages” view which is facilitated by searching with information about the individual.
To understand organizational-level Direct endpoints in contrast to personnel-level Direct endpoints, it’s helpful to examine the four possibilities supported by the DirectTrust Trust framework.
|
Direct Certificate Issued to an Identity-Trusted Entity |
|||
|
Direct Address Endpoint Types |
Domain-Level Certificate | Address-level Certificate | |
| Organization-Level Direct Address Endpoint | 1 | 3 | |
| Personnel-Level Direct Address Endpoint | 2 | 4* | |
*Used for Individual Patient Direct addresses as well. Patient Direct addresses are not included in the DirectTrust Aggregated Directory.
OPTION 2 EXAMPLE (Click to expand) – Domain-Level Certificate issued to a Personnel-Level Direct Address (Personnel Endpoint):Direct address [email protected] is associated with a Domain-level certificate. The subject of the certificate is the organizational entity: DirectTrust.org from Washington, District of Columbia, US.
OPTION 1 EXAMPLE (Click to expand) – Domain-Level Certificate issued to an Organization-Level Direct Address (Departmental or Workflow Endpoint): Direct address [email protected] is associated with a Domain-level certificate. The subject of the certificate is the organizational entity: MaxMD from Fort Lee, NJ, US.
Certificate strategy option 1 (departmental or workflow addresses) and option 2 (individual personnel addresses) are the most common.
The DirectTrust Directory Policy requires each organization using Direct to submit at least one Direct address to the Directory. That Direct address can be a general purpose departmental or workflow address (e.g. endpoint use case “provider-to-provider-data-exchange” or “care-coordination”), organization-level address or an address established to handle Directory-related communications (endpoint use case “directory-steward”), but the requirement also can be met by submitting individual personnel addresses as well.
Regardless, if personnel-level Direct address endpoints are included in the Directory or marked as “unlisted” for the provider’s listing, it is critical to have the provider included in the Directory. Often patients don’t know the name of the organization their doctors work for, so the optimal way to search must be based on knowing only a provider’s name. Once a provider’s name and general vicinity of practice are known, the provider’s NPI number can be determined by searching the NPPES Registry and a search of the DirectTrust Directory based on NPI ensures the possibility of an exact match.
Certificate strategy option 3 is utilized when the organization associated with the domain is a different legal entity from the organization responsible for the Direct address.
OPTION 4 EXAMPLE (Click to expand) – Address-Level Certificate issued to a Personnel-Level Direct Address (Patient Endpoint): Direct address [email protected] is associated with an Address-level Certificate. The subject of the certificate is an individual entity from Westerly RI, US. The DirectTrust CP prohibits individually identifiable information from being carried in the certificate associated with an individual’s Direct address and so the addresses supplied to patients must not utilize the patient’s name. This rule also applies to the Subject Alternative Names, so the person’s email address isn’t appropriate for use in the certificate either. Other methods of associating the identity-proofed person with the certificate must be applied.
OPTION 3 EXAMPLE (Click to expand) – Address-Level Certificate issued to an Organization-Level Direct Address (Direct Endpoint): Direct address [email protected], is associated with an Address-level certificate. This certificate strategy is utilized when the organization associated with the domain is a different legal entity from the organization responsible for the address. The subject of the certificate is the organizational entity: We Luv Kids, but the organization offering Direct services (and controlling the domain Konzacare.org) is a different legal entity.
Certificate strategy option 4 is typically utilized for patient-level Direct addresses.However, a single healthcare provider may receive a Direct address that is bound to an address-level certificate. In this case, the entity that is identity-proofed is an individual provider, not the organization they work for. The certificate behind the Direct address only identifies the practitioner, not an organization, as the covered entity. Within the DirectTrust Trust Framework a Covered Entity (CE) can be an individual, organization, or agency that protects the privacy and security of health information and provides individuals with certain rights with respect to their health information. Covered Entities in this CP are as defined under HIPAA at 45 CFR 160.103.
The question becomes how to optimize searching for that provider’s Direct endpoint. The DirectTrust Aggregated Directory requires organizational information to be included for all providers so Direct address endpoints can be found by searching on the provider’s information or the provider’s organization information. If a provider truly has no associated organization, or if a provider works for one or more organizations, but receives their Direct messages outside of their employers’ systems, there are two options for including this type of Direct address endpoint in the Directory.
First, the provider can be included in the DirectTrust Aggregated Directory multiple times, once for each organization where the provider works. The downside of this approach is that the Directory is relying on the attestation of a provider about their place or places of employment. It’s not optimal, but it isn’t prohibited by the DirectTrust Directory Policy.
Second, the provider can be listed in the Directory just once using only their personal information for both white pages and yellow pages searching. In essence, the provider’s name and level 1 NPI become the information used when searching for an organization. It’s not optimal and it doesn’t support advance Directory queries that offer both a white- and yellow-pages views that link together, but it works.
Are You Using Direct Secure Messaging to Its Full Potential?
Different types of Direct addresses serve different purposes. To optimize the value derived from using Direct Secure Messaging, organizations need to deploy the right kinds of address endpoints to support their different information exchange use cases. This endpoint and endpoint use case information needs to be discoverable in the DirectTrust Aggregated Directory.
A clear set of planned Direct Secure Messaging use cases with appropriately specified address types and a well-designed Directory utilization strategy will save time and money, and improve the overall results achieved from implementing the secure communication capabilities of Direct.
APPENDIX:
