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