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


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


Epic


FEI


GE
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.
IBM
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.
MedAllies


Medicity


Siemens
Yes
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
yes
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


Alere


Allscripts


American Academy of Family Physicians


Argonne National Laboratory


Atlas Development


Axolotl


Cautious Patient


Cerner


Christus Health


Clinical Groupware Collaborative


CMS


Covisint
yes

DoD


eClinicalWorks


EHR Doctors


Emdeon


Google


Greenway Medical Technologies


Healthcare Information Xchange of NY


High Pine Associates


ICA


Inpriva


Intel


Kryptiq


Massachusetts eHealth Collaborative


Medical University of SC, South Carolina Research Authority


MedNet


MedPATH Networks


MedPlus/Quest Diagnostics


Microsoft


Mirth Corporation


Misys Open Source Solutions (MOSS)


MobileMD


NIH NCI


NIST


NoMoreClipboard.com


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


Rhode Island Quality Institute


Secure Exchange Solutions


Surescripts


Techsant Technologies


TN State HIE


VA


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