Policy Questions for Implementations Call for Consensus

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