The Direct Standard® remains one of the most widely deployed protocols for trusted clinical communication because it’s identity-verified, encrypted, and secure for sensitive data. When it comes to representing Direct addresses inside structured documents, implementers often run into a key question:
How do you clearly distinguish a Direct address from a regular email address in CDA and FHIR?
Let’s walk through best practices for both.
Why This Matters
Direct leverages email protocols, but it is much more than basic email — it carries trust, identity, and certificate binding. By representing them in structured documents correctly:
- Systems can reliably distinguish secure vs non-secure endpoints
- Workflow routing becomes easier
- Directory matching and trust decisions are supported
So the goal is simple: make Direct addresses explicit, machine-interpretable, and easier to find and use when sharing information.
Representing Direct Addresses in CDA
In HL7 CDA R2, the telecom data type is used for contact points. However:
- CDA requires mailto: for endpoints that use email protocols
- There is no native way to distinguish a secure Direct address endpoint from a regular non-secure email address
Recommended Extended Semantics for CDA
In CDA, the use attribute to supports extended semantics:
- DIR → Direct address for a single professional at an organization.
- PUB → Direct address for a workflow endpoint at an organization.
Individual Provider Direct Address Example
| None
<telecom use=”DIR” value=”mailto:[email protected]”/> |
You can also combine the extension with standard CDA use codes:
| None
<telecom use=”WP DIR” value=”mailto:[email protected]”/> |
Workflow Direct Address Example
| None
<telecom use=”PUB” value=”mailto:[email protected]”/> |
You can also combine the extension with standard CDA use codes:
| None
<telecom use=”WP PUB” value=”mailto:[email protected]”/> |
These patterns are explicitly documented in the HL7 CDA Examples IG and represent current best practice.
Understanding DIR vs PUB
The semantic distinction is subtle but important:
DIR (Direct – for a single professional’s use)
- Represents a Direct address provisioned to a specific person at an organization where they work
- Implied information processing:
- Messages are intended for direct consumption by a specific person at their associated organization
PUB (Public / Workflow Use)
- Represents a Direct address provisioned to an organization for a group, team, department to use to support an information processing workflow
- Implied information processing:
- Messages are not intended for direct consumption by a specific person at their associated organization. A whole department or group of people are permitted to access the information when it arrives at their organization.
- This type of address is established as an “intake queue” supporting the workflow associated with a specific use case.
Key Insight
This is a supported extension for the use attribute vocabulary in CDA. It is backward compatible, human readable, and increasingly adopted in practice.
Representing Direct Addresses in FHIR
In HL7 FHIR R4, Direct addresses are represented using the ContactPoint data type.
Semantic Mapping
| Concept | FHIR Representation |
| Direct address | system = email |
| Direct address value | value = “[email protected]” |
| Work vs home | use = work |
| Direct indicator | us-core-direct extension |
Example: PractitionerRole with Direct Address
Below is a FHIR R4 JSON example for Dr. John Smith, a fictitious persona created to demonstrate representation of an Internal Medicine physician (taxonomy: 207R00000X), working at The Westerly Hospital.
Supporting FHIR Resources in this example:
- Practitioner → John Smith, MD
- Organization → Yale New Haven Health
- Location → The Westerly Hospital
CDA vs FHIR: Conceptual Alignment
| Concept | CDA | FHIR |
| Base transport | mailto: | system = email |
| Direct Indicator | use=”DIR” or use=”PUB” |
us-core-direct extension |
| Work/home context | use=”WP” / HP | use=”work” / home |
| Multiple semantics | space-separated use | structured elements + extensions |
The Big Picture
Whether you’re working in CDA or FHIR, the principle is the same: A Direct address is a trusted endpoint, not just an email address. By explicitly representing that distinction, you improve interoperability, enable more effective routing and processing of information, and strengthen trust frameworks across networks.
Bottom Line
- CDA: Use mailto: + use=”DIR” / use=”PUB”
- FHIR: Use ContactPoint + us-core-direct extension
Together, these patterns ensure that Direct messaging remains discoverable, actionable, and trustworthy when information is being exchanged via documents across the healthcare and social care ecosystem.