Implementation Group Call for Consensus: Consensus Proposal v1.0

Consensus Proposal

DUE: June 30, 2010

Workgroup Participants:
Endorsement (Yes or No)
If No, what can be changed to make it Yes?


American Academy of Family Physicians

Argonne National Laboratory

Atlas Development

We suggest the final specification include more information on:
1. Security of DNS and SMTP servers. (can be covered in a separate security specification)
2. More specifics on TLS: such as protocol version, encryption & key exchange algorithm, key strength
3. DNS administration as required here is not trivial. Recommend effort to be made to come up with functional models, make recommendations on useful applications/tools, and or create reference implementations.
CAL eConnect


Yes (With Concern)
The overall security of NHIN direct relies heavily on the proper design, implementation, use and enforcement of policies and procedures regarding the handling and storage of private keys, timely checking for certificate revocation, end point security, etc., so, there are many items not addressed in the consensus proposal that do affect the security of NHIN Direct.
California Health and Human Service Agency

Cautious Patient

Center for Democracy & Technology


Clinical Groupware Collaborative
Yes (MPS)



Community Choice PHCO


Yes with comment
1. Source to Source HISP and Destination HISP to Destination should not require to necessarily implement SMTP. This is a backbone protocol mandate.
2. The source and destination in addition to embedded content payload MUST also support URL based content delivery embedded within the message.
EHR Doctors


Yes with comment
We suggest the following clarification:
Under "Source and Destination Connectivity",
3rd paragraph: "E-mail connectivity MUST support SMTP client..." change to "Source/Source HISP E-mail connectivity MUST support SMTP client..."
4th paragraph: "E-mail connectivity MUST support POP3 or IMAP4 client..." change to "Destination/Destination HISP E-mail connectivity MUST support POP3 or IMAP4 client..."

We request the following clarifications:
Under "Add-on Connectivity" -> "HISP-HISP"
"HISPs MAY support additional protocols for HISP-HISP transport, but Source HISPs SHALL BE responsible..." change to "HISPs MAY support additional protocols for HISP-HISP transport, but Source or Source HISPs SHALL BE responsible..."

Under "NHIN Exchange Connectivity" -> "NHIN Exchange to Minimal End-to-End Connectivity"
"NHIN Exchange participants sending to non-NHIN Exchange SHOULD..." change to "NHIN Exchange participants sending to non-NHIN Exchange participants without XDR capabilities SHOULD..." and edit the table accordingly., inc

Florida State HIE/Agency for Health Care Administration

This needs a forthright statement that under no circumstances is PHI sent over the Internet in an unencrypted form, notwithstanding this statement currently in Cons. Prop v1.0: "Source HISPs MUST be capable of accepting incoming messages with unencrypted payloads from Sources, and securing and transmitting them using the Security Agent model documented in the appendix below, in accordance with the Security and Trust Consensus Proposal "

If perchance the proposal does call for sending unencrypted data over the Internet under any combination of MAYs and MUSTs then I wish to change my vote to NO.
The Spirit of the Consensus Proposal is good, but there are still fine details that are ultimately unnecessary and if we are held to them over the coming months will cause major problems. I am concerned that the text includes too much of the “Security Agent” . The Security Agent is a fine example of how to implement and might inform defining an edge protocol, but should not be the only way to satisfy the HISP-HISP interoperability layer. The HISP-HISP interoperability layer for SMTP needs to be defined in interoperability terms that can be implemented by independent developers (internal IT, vendor, service provider, or open-source).

Greenway Medical Technologies
Yes with comment
An explicit statement that SOAP/XDR end-to-end connections are NHIN Direct connections and should be explicitly allowed is needed.
Harris Corporation
Same comments as GE.

Healthcare Information Xchange of NY

High Pine Associates

HLN Consulting, LLC
YES but with comments
1. Unless I missed it somewhere, I have not seen any comment about the need for HISPs to deal with standard virus protection and the like, given an SMTP-based backbone. Many standard virus scanning products do not deal well (or at all) with ZIP files yet that is our preferred packaging.
2. In the intro to the consensus pr​oposal there is a statement, "Use of the term "NHIN Exchange" in this document means the exchange described as such on the ONC web site" but the link goes to a site describing NHIN Limited Production Exchange in which most (if not all) NHIN Direct users will NOT participate. Perhaps this link really was meant to go to something describing NHIN Exchange specifications but really I suspect this is just a gloss for IHE standards.



Yes WIth Conditions/ Comments
We understand the need to create an easy-to-adopt entry path by adopting SMTP.While ONC has repeatedly supported the use case for an easy rapid pathway for providers to move quickly to NHIN Exchange, we feel that the SMTP approach will not facilitate such a migration, but rather create a comfort zone for organizations to stay with and avoid migration to a more robust and functional approach.We are specifically concerned that the selection of SMTP will require entities currently in NHIN Exchange to implement and maintain an SMTP gateway indefinitely to communicate with providers who don't have an EHR and those with an EHR but no HIE connectivity.This eventual persistent duality significantly increases total cost of ownership for HIE for every organization which does support NHIN Exchange, indeed a penalty for a higher level of commitment to HIE supporting true meaningful use.

We also believe that unstructured email is a dead-end in that it doesn’t support the quality improvement, data mining and decision support functionalities at the core of true meaningful use, and that SMTP should only be considered if it provides a requirement to use/send STRUCTURED messages.Given that the NHIN Direct directory service and certificate exchange will probably require a specialized email client, we don't believe requiring this additional requirement would impose significant incremental overhead or represent a significant barrier to implementation.Thus, we would like to add structured message requirements to the Consensus document.

We are also concerned about security over multi-hop exchanges. The document seems to agree with this concern when it explicitly states that security issues remain and have not yet been addressed, and that the Security Workgroup will have to address them.This will need to be addressed before the final version of the document is completed and adopted. We categorically reject the notion that a transport specification can be validated in any standards development context prior to resolution of known issues with security.This concern has already been expressed by others on the NHIN Direct calls, but has not yet been addressed adequately in the consensus document.

Also, in the first part of the Appendix, where the document describes the meaning of the two Message Disposition Notifications of "displayed" and "processed", one would have expected that 'displayed' means displayed, and 'processed' meant parsed and stored or integrated into the EHR.Instead the document defined “processed” as follows: "The disposition-type of processed SHALL be interpreted to mean that the message has been accepted by the Destination HISP but has not been delivered to the Destination."This does not seem to make sense.How can it be "accepted" by the Destination but not "delivered" to the Destination.This will need to be addressed in the next version of the document.

Additionally, in the Appendix there is a statement about security when sending a message that reads "Sending A Message Fetch configured private keys for the endpoint and sign the original message with each."If the endpoint is the 'receiver' and we are the 'sender', we are not the endpoint.If we are not the endpoint, then we cant "fetch the private keys for the endpoint".The critical element here is that private keys never are known to anyone but you.So how can the sender fetch the private keys of the endpoint?.Maybe the document meant "fetch the public keys of the endpoint".This will need to be clarified in the next version of the document.

Two final comments.
-- First, we strongly recommend that the document describe how the transport standards and requirements relate back to the transport and security standards adopted in the ONC Interim Final Rule.It will be critical to explicitly document and MAP/Crosswalk, as appropriate, the standards being adopted in the Consensus document and the standards adopted for EHRs by the IFR.
-- Second, we strongly recommend that future open processes to reach consensus on critical documents such as this one be open for review and comment for at least 2 weeks (if not a full 30 days).We understand that this document was the culmination of many discussions, but still, once it is out for a more expansive vetting, an appropriate comment period should be offered.


Massachusetts eHealth Collaborative

ME State HIE/Health Infonet

YES (with comment on conditions that change this to NO)
As requested, we expect that in the preamble for transport specification, it will be clarified that NHIN Direct allows XDR connectivity among participating HISPs acting in ‘non-NHIN Exchange context’ . This is also aligned with the Greenway's comment, and having that perspective be clear throughout. Our vote changes to NO without this.
Medical University of SC, South Carolina Research Authority



MedPATH Networks

Medplus/Quest Diagnostics


Mirth Corporation

Misys Open Source Solutions (MOSS)
Overall the proposal looks good. However, I agree with Greenway Medical. The framework should support SOAP/XDR protocols in the near term and a clarification around it would be helpful.





Oregon Health Information Exchange Planning Team

Redwood MedNet


Rhode Island Quality Institute

Secure Exchange Solutions

See question on Consensus Proposal discussion tab, requesting clarification about whether/how the sender is supposed to receive notification that a message was rejected.
Social Security Administration

Sujansky Associates


Techsant Technologies





Other Implementation Group Participants: