Pub-Sub Deployment Model with HISPs

From Direct Project
Jump to: navigation, search


Pub-Sub Direct Implementation using HISPs and Desktop STA

Status of this Specification

This specification is in Draft state.

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.

The Specification uses proprietary elements which are IPR protected.


Pub-Sub model using HISPs and RFC-1218 Naming Structure, X.509v3 certificates compatible with Federal PKI.


A Desktop pub-sub connection is created between two nodes A1-B1, Certificate and Provider Directory information is obtained from local HISP X.500/LDAP State X.500/LDAP, National X.500/LDAP, and other country X.500/LDAP


NwHIN pub/sub DIRECT architecture using desktop STA, Internet MTA, S/MIME, HISPs, X.500/LDAP, DNS, X.509v3, Federal PKI, logical "AND" Gate (1898 US patent 613809)


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."


Pub/Sub Node communicates to Pub/Sub Node via STA, sources destination endpoints and email address from Provider Directory Use Case 1 and 2 S&I Framework, userCertificate;binary



Security Considerations

Consensus Secure Transport Agents to Mail Transport Agents


pahisp flow.jpg

This section is non-normative.


Peter Bachman
Stephen Beller


Bradner, Key words for use in RFCs to Indicate Requirement Levels, RFC 2119


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.