Addressing Specification
Health Internet Addressing
Status of this Specification
This specification is in version 1.2.
1.0 Endorsements
Version 1.0 passed a call for consensus at the Working Group level, and had one objection at the Implementation Group level (intended to be addressed in 1.1)
Addressing Specification Workgroup Endorsements
Addressing Specification Implementation Group Endorsements
Addressing Specification Other Endorsements
May 6th Face to Face meeting Consensus vote
IPR Statement
By contributing to this specification, all contributors warrant that all applicable patient or other intellectual policy rights have been disclosed and that any of which contributors are aware of will be disclosed in accordance with the NHIN Direct project IPR Policy.
Abstract
This specification provides a mechanism for addressing of origination points and endpoints for health information exchange relative to the NHIN Direct User Stories. The minimal intent is to support physicians, hospitals, clinical reference laboratories, pharmacies, other ancillary health care providers, and the patients they serve.
Table of Contents
Introduction
Purpose
This addressing specification provides a standardized addressing mechanism supporting discovery of the HISP that routes or manages health information exchange on behalf of the individual origination point or endpoint of a health information exchange transaction.
Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant."
Synopsis
Health Internet Addresses consist of a Health Domain Name portion, which is a fully qualified domain name, and a Health Endpoint Name. The intent of a Health Internet Address is to provide a method of routing from an origination point to the addressed recipient, not to provide a single, definitive ID for the intended recipient. The same real-world person may have multiple Health Internet Addresses (e.g. one address for each practice location, multiple addresses for different processing purposes such as labs, routed to the EHR, vs unstructured messaging, routed to the secure messaging client and copied to the chart).
Health Domain Name
A Health Domain Name is a string conforming to the requirements of RFC 1034.
A Health Domain Name identifies the organizations that assigns the Health Endpoint Names and assures that they correspond to the real-world person, organization, machine or other endpoint that they purport to be. Example: nhin.sunnyfamilypractice.example.org. A Health Domain Name MUST be a fully qualified domain name, and SHOULD be dedicated solely to the purposes of health information exchange.
Organizations that manage Health Domain Names MUST maintain NHIN Direct HISP Address Directory entries for the Health Domain Name, as specified by the Abstract Model, and corresponding to rules established for concrete implementations of the Abstract Model.
Organizations that manage Health Domain Names MUST ensure that at least one concrete implementation of the HISP to HISP abstract transaction is available for each Health Endpoint Name.
Organizations may take on the HISP role or assign this function to another organization playing the HISP role.
Health Endpoint Name
A Health Endpoint Name is a string conforming to the local-part requirements of RFC 5322
Health Endpoint Names express real-world origination points and endpoints of health information exchange, as vouched for by the organization managing the Health Domain Name. Example: drsmith (referring to in individual), sunnyfamilypractice, memoriallab (referring to organizational inboxes), diseaseregistry (referring to a processing queue).
Security Considerations
This section is a placeholder for future work.
Examples
This section is non-normative.
Health Internet Addresses may be formatted in the following ways:
| Format |
Formatting Rules |
Example |
Notes |
| Email Address |
Health Endpoint Name + "@" + Health Domain Name |
[[1]] |
|
| XD* Metadata |
Email Address in <need details for updated XDR spec> |
<TBD> |
The actual formatting requirements are specified in the concrete implementation specifications.
Authors
References
Bradner, Key words for use in RFCs to Indicate Requirement Levels, RFC 2119
Mockapetris, Domain Names -- Concepts and Facilities. RFC 1034
Resnick, Internet Message Format, RFC 5322
NHIN Direct Project, NHIN Direct Abstract Model, Abstract Model
Copyright
By contributing to this specification, all contributors agree to license contributions according to the Creative Commons Attribution 3.0 License which is incorporated into this document by reference.