The Redwood Mednet Demo is designed based on the consensus proposal that can be found at http://nhindirect.org/Consensus+Proposal

For the demo purposes the following sections capture the implementation details:

Backbone (HISP to HISP) protocol and configuration:


The protocol being used for backbone communication is SMTP. All the 3 HISP's support SMTP protocol at a minimum for message exchange.

To support this the following configuration will be performed by the various participants:

DNS MX Records: (These are needed for SMTP servers to resolve the health internet domain name).

For Redwood Mednet SMTP server a MX record with health internet domain name of "nhin1.rwmn.org" will be added in the Redwood Mednet DNS.
For Long Beach SMTP server a MX record with health internet domain name of "nhin.whinit.org" will be added to the Long Beach DNS.
For Santa Cruz SMTP server a MX record with health internet domain name of "nhin.santacruzhie.org" will be added to the Santa Cruz DNS.

Certificate Resource Records:

For Redwood Mednet SMTP server a CERT resource record with a subject name of "nhin1.rwmn.org" will be added in the Redwood Mednet DNS.
For Long Beach SMTP server a CERT resource record with health internet domain name of "nhin.whinit.org" will be added to the Long Beach DNS.
For Santa Cruz SMTP server a CERT resource record with health internet domain name of "nhin.santacruzhie.org" will be added to the Santa Cruz DNS.


Server Certificates:

All the HISP's need to provide secure TLS channels to the edges. In order to do this each of the HISP's need to support a server certificate that can be used to provide the necessary secure configuration.:

HISP Services:


Redwood Mednet HISP:
  • The Redwood Mednet HISP provides the SMTP backbone service.
  • For edge connectivity to Dr R.M , the HISP supports SOAP + XDR protocol.
  • For security the HISP will support a server certificate that can be used to establish a TLS channel.
  • The HISP translates all message semantics including payload from SOAP + XDR protocol to SMTP protocol. This involves constructing a MIME message from a SOAP message invocation.
  • The MIME Message will be encrypted and signed by the Certificate assocaited with the HISP.

Long Beach HISP:
  • The Long Beach HISP provides the SMTP backbone service.
  • For edge connectivity to Dr L.B , the HISP supports REST protocol.
  • For security the HISP will support a server certificate that can be used to establish a TLS channel.
  • The HISP translates all message semantics including payload from REST protocol to SMTP protocol. This involves constructing a MIME message from a REST PUT.
  • The MIME Message will be encrypted and signed by the Certificates assocaited with the HISP.


Santa Cruz HISP:

  • The SantaCruz HISP provides the SMTP backbone service.
  • For edge connectivity to Dr S.C the HISP supports the POP/IMAP protocol.
  • For security the HISP will support a server certificate that can be used to establish a TLS channel.
  • The HISP will encrypt and sign the MIME message by the certificates associated with the HISP.


Payload for the Demo:

For the Demo the payload will be a SMTP MIME Message which is the common payload that can be used by all HISP's without any additional meta data requirements for the edges.
A C32 document or just plain text message can be used for demonstration purposes.

Security Configuration between HISP's:


For security purposes the NHIN-D Agent developed by the NHIN Direct team will be used by the implementation teams. The java version of the agent is present at http://code.google.com/p/nhin-d-jagent/ and the C# version is present at http://code.google.com/p/nhin-d-agent/.
For the NHIN D Agents to be used the certificates have to be issued from a trusted anchor and has to be imported into the keystore for each of the HISP's. For demo purposes the certificates will be issued by the same CA and each of the implementation team will import the certificates issued to their own domain name as the primary certificate that will be used for signing and encryption. In addition to importing their own certificates, the HISP's will have to import the root CA as an anchor to trust the other domains.

Sequence Diagrams:

A top level sequence diagram to send and receive message from an end user perspective is described below. All the HISP's will have the same type of interaction except for the protocols that are used.


Sequence1.jpg