Messages for Key Stakeholders

Messages for Key Stakeholders - Call for Communications workgroup consensus

DUE: December 7th

Link to the 4 documents

Workgroup Participant Organization	Endorsement (Yes or No)	If No, what can be changed to make it Yes?
Akira Technologies, Inc
Alere
Allscripts
American Academy of Family Physicians
Atlas Development
Axolotl
CareSpark/Serendipity Health
Cerner Corporation
Christus Health
Clinical Groupware Collaborative
CMS
Covisint
CSC
DoD
eClinicalWorks
Emdeon
Epic
FEI
Garden State Health Systems
GE	NO	These presentations are not ready to be approved. 1) They still use NHIN Direct phrase 2) Both States and HIE slides 2.1) I don't understand why there is a need to have one targeting States and another HIE. The message should be the same. Is this differentiation simply because the two audiences don't always see themselves as the same? If it is an audience perception, then I understand but we should combine these two. 2.2) A common concern I hear from this audience regarding direct is that direct does not contribute to a longitudinal record. This is not a problem we can fix, but we can point out that Direct is a stepping stone that gets people creating and using content; where they will better understand the need and benefit of a longitudinal record. 2.3) A benefit to this audience is that they can get their provider community communicating while they work out privacy policies, and policies about special case data. 2.4) Page 2 of these are not very helpful to this audience. In fact this page tells this audience that they are of no value. 2.4.1) They would not be providing e-mail client, but rather they might be providing e-mail services 2.4.2) They would potentially be providing identity services and trust stores 2.4.3) They would be harmonizing policy, privacy, security, and service agreements 3) Provider slides 3.1) I would add a benefit - Direct solution is content agnostic; enabling communications of simple content today with easy transition to more structured and coded documents that can enable automation and clinical decision support 3.2) The statement that if one knows a Direct address that one can send securely needs to have a caveat related to security. I think we could prefix something like 'when fully enabled...' to put enough wiggle room around the use of automated DNS when properly configured, LDAP when properly configured, or prior-messages when properly configured. This additional statements are not necessary, but the prefix likely is. 3.3) Page 2 -- This page should give two or possibly three pathways. related to the deployment models. I know we want to hide this choice, but hiding solutions that someone might find useful is trouble. I would be especially worried that we are telling them to use an email when a good and available choice today is Direct integrated into an EHR. 3.4) Page 2 -- Why is there 'what does a vendor need to implement direct?' on this page? 4) The Vendor slides 4.1) These are the worst slides of all. I have been intimately involved in the Direct project and work for a vendor; I could not use hardly any of the information on these slides to convince any vendor to go through the effort to implement Direct. 4.2) Most of the statements on these slides are unsubstantiated claims. I am not going to say that there is no way they could be true, but I don't see how they are and there is no supporting material. 4.2.1) State 1 MU does not call for anything like Direct. And the testers are not looking for anything like it. 4.2.2) I don't see how Direct lowers costs to a vendor, it adds new services that they don't have today and are uncomfortable with . Thus meaning more engineering and support services necessary. 4.2.3) There is no universal addressing... even if there was it would benefit ALL forms of communication, not just Direct. 4.2.4) Minimal requirements of an e-mail... this statement is a statement against vendors wanting to do anything about it. This tells them that they should ignore Direct. 4.2.5) How does Direct facilitate 'all levels of automation'? Especially when Direct allows for a sender to send an unstructured document with no metadata as a bare email attachment. This FORCES human intervention. 4.2.6) how does this reduce long term communications costs? It means that one must put in DUAL pathways, that seems like it is doubling costs. Adding need to support email infrastructure. 4.2.7) gross overstatement of 'active participation'. I am not sure what value the statement of 200 would mean to the vendors anyway. 4.2.8) Why is "IDN" listed on vendor? I realize that perception is that IDN are made up of monolithic vendors, but this is not is not a helpful statement in this slide, better to lump IDN with States and HIEs. Any benefit to a typical EHR vendor would not be very helpful to an IDN vendor. 4.2.9) The fact that Direct is driven by ONC is potentially useful to a vendor if we knew that it would be a Meaningful Use criteria. Having it be a "NHIN standard" doesn't mean anything. 4.2.10) To a EHR vendor, it doesn't help to say that basic email client and internet connection are minimal requirements. At best this tells the EHR vendor to ignore Direct, at worse this tells them that they now must figure out how to seamlessly integrate ALL POSSIBLE email clients (note that CCHIT has mandated that the MU encryption functionality must be seamlessly integrated and can NOT use a standalone encryption application). 4.3) still using "NHIN Direct"
Google
Greenway Medical Technologies
GSI Health
Harris Corporation
Healthcare Information Xchange of NY
High Pine Associates
HLN Consulting, LLC	Yes	Comments previously provided
IBM
ICA
Inpriva
Intel
Kryptiq
LabCorp
Massachusetts eHealth Collaborative
MedAllies
Medical University of SC, South Carolina Rese
Medicity
MedNET
MedPATH Networks
MedPlus/Quest Diagnostics
Microsoft
Mirth Corporation
Misys Open Source Solutions (MOSS)
Mobile MD
NextGen Healthcare Information Systems, Inc.
NIH NCI
NIST
NoMoreClipboard.com
NYC Dept. of Health and Mental Hygiene’s PCIP
Oregon HIE Planning Team	Yes
Redwood MedNet
RelayHealth
Rhode Island Quality Institute
Secure Exchange Solutions
Siemens	Prelim comment	For HIE, I suggest that the pitch and the title not be limited to "States" since States are just one example of HIEs at a certain scale. Other forms of HIOs, such as RHIOs that handle metro areas or portions of states, or even IDN/ACO-based HIOs, ought to be addressable in the same presentation, so I wouldn't want them to feel like there is not a message for them.
Surescripts
Techsant Technologies
TN State HIE
VA
VisionShare