Policy Questions for Implementations Call for Consensus

From Direct Project
Jump to: navigation, search

Documentation and Testing Workgroup Call for Consensus: Policy Questions for Implementations

DUE: 9/22/2010

When a healthcare delivery organization or clinician decides to exchange data using Direct, there are a number of questions surrounding workflow and organizational policies that must be answered. These questions are raised by the exchange of clinical data provided by Direct, but their answers must be agreed upon by the users who exchange the data in order to ensure a efficient, secure, and acceptable workflows for clinical care. This document lists questions that should be considered and answered by Direct's users and guidance as to how their answers may affect how data exchange is conducted
A note: it seems unlikely that the document will ever be used in this format; instead, its content would probably be taken by the Communications Workgroup and made pretty. This call for consensus focuses only on the content, not the format.

You can review the
Policy Questions for Implementations

Company or Individual
Endorsement (Yes or No)
If No, what can be changed to make it Yes?
Workgroup Participants
CareSpark/Serendipity Health
Yes, but
Agree that more policies around Security and Trust items as articulated by GE and ONC and more guidance on how to reconcile different email addresses as highlighted by IBM. This is a good start to lead to the much needed discussion to continue fleshing out other issues for best practice guidance.



Yes, but

Need a few more policies around Security and Trust items :

  • ‘Do I need a certificate for every individual?’ to cover the fact that some addresses are individual addresses while others are group addresses and some addresses have a certificate while other addresses share a common certificate.
  • ‘How do I get the recipient's digital certificates?’ to explain decision between discovering and thus publishing via DNS, LDAP (healthcare provider directory), manually, or prior-email exchange.
Harris Corporation

HLN Consulting, LLC
Yes, with a suggestion
Just one thought: Might be good to mention at the top of this document (or elsewhere) that a participant needs to be aware of the legal requirements that are at play in a jurisdiction. The document makes it sound like everything (like consent, for instance) is completely at the discretion of the participant, when this is in fact not true for a number of these topics.
Yes, but...

Excellent start to a very important document. Two concerns:

  • For the Sender we need to advise them to be sure they are sending to the right place - are using the correct, appropriate address which will get their content to the person it is intended to get to. This point is expressed in other comments as well and I think is a critical concern for the Sender prior to sending anything.
  • In the question regarding using the same e-mail address for Direct and non-Direct I think we should strongly advise, if not completely insist, that different e-mail addresses be used. The words in this section are not strong enough. And we need a risk assessment that addresses specifically this use of one e-mail for both kinds of interactions. I can imagine so many things going wrong, missed messages, accidentally choosing the wrong address in the contact list, auditing confusion just to name a few.


For where we are, this is a reasonable statement. I agree with adding the other questions, on this page, to be included. This list is going to evolve continually, especially as real-world pilots emerge, so we think we should baseline this, and not worry about "consensus" implying that we've finalized the list of questions.
Redwood MedNet
this is not the final list, but it needs to move on at this time so that new questions can be cultivated and added to the work queue for answering. i think the biggest unanswered questions are contractual risk and liability issues that are above the pay grade of the direct team.
Other Implementation Group Participants
Akira Technologies



American Academy of Family Physicians

Argonne National Laboratory

Atlas Development


Cautious Patient


Christus Health

Clinical Groupware Collaborative





EHR Doctors



Greenway Medical Technologies

Healthcare Information Xchange of NY

High Pine Associates





Massachusetts eHealth Collaborative

Medical University of SC, South Carolina Research Authority


MedPATH Networks

MedPlus/Quest Diagnostics


Mirth Corporation

Misys Open Source Solutions (MOSS)





NYC Dept. of Health and Mental Hygiene’s PCIP

Oregon HIE Planning Team

ONC (Arien)
Yes, but

Document is fine but incomplete. I agree with John's comments relating to security considerations. Other questions of this ilk:

  • What is required for provider identity assurance?
  • What is required for provider authorization?
  • What is required for patient identity assurance/authorization?
  • What policies will you establish for trusting the certificates of other organizations? For maintaining/refreshing your list of trusted anchor certificates?
  • What general security policies (security audits, logging, scanning, training, etc.) will you require?
  • ....
    Also, I've gotten a number of questions from folks who are confused as the the intent. I believe the abstract/preamble needs to clearly state that this document is *not* intending to set policy, just to outline areas where policy should be set.

Rhode Island Quality Institute

Secure Exchange Solutions


Techsant Technologies

TN State HIE


Agree with Security & Trust comments already made above.
Garden State Health