Company
Vote (Yes/No)
Comments
Allscripts


American Academy of Family Physicians


Axolotl


California Health and Human Service Agency


CareGroup/BIDMC


CareSpark


Cautious Patient


Cerner


CGI Federal


Clinical Groupware Collaborative


CSC


CSC Healthcare Group


eClinicalWorks


Epic
Yes

Gartner
Yes
But ... the current language should be made more clear that NHIN Direct is not the designator or the enforcer of content standards.
As it stands it will be read by some as allowing only IFR-compliant structured documents. I am sure that this not the intent but people do tend to read specs in a lawyerly fashion.

I would dearly like to see specific user stories that describe the impedance-mismatch scenarios even though these are not clinical variations in the situation being described.
GE


Healthcare Information Xchange of NY


HLN Consulting, LLC


IBM
No
Initial review of the user stories finds them vague and confusing in terms of driving a solution. The level of detail varies from extremely high level to very detailed. A consistent and cohesive approach would be much more helpful.
A couple of particular concerns to explain the general concern:
1) In some of the user stories the story suggests to me that the receiver is expected to discover which patient is being referenced in the received content. For example, statements like "If this is a new patient for the practice, a new patient is created in the EHR" and "triggers various workflows in the patient registration and hospital clinical systems to create the clinical order and associate it with the patient account and the schedule" suggest that there is a requirement for creation of new patient record and association of incoming data with existing data. There are several ways to do this but the simpliest of the possibilities listed under "Data Exchange" seems unable to support this requirement, since "the simpliest case only a textual description is transmitted" cannot have enough machine processable information to allow an EHR to add a new patient or even decide if a new patient is needed. We need to be consistent on this subject. Either the patient identity is out of scope, in which case a human with knowledge outside of the transaction is deciding whether to add a new patient or not. Or in scope, in which case the Data Exchange sections should talk about which patient demographics are needed.
2) Allowing a list of possible "data exchange" make it very difficult to determine what is required. Are we saying that each concrete implementation must support all? I am very concerned that #1 is not going to be useful as it doesn't have enough machine codable content to allow for any reasonable processing on the receiving side.
Informatics Corporation of America


Kaiser


Massachusetts eHealth Collaborative


MedAllies


Medicity


MedPlus/Quest Diagnostics


Microsoft


Mirth Corporation


Mobile MD


NIST


NCI


Oracle
No
Provider to Specialist "The referral reason is described in the message" In both the CCD and the CCR, the purpose is described within the document itself. Any text in the message should be on topics that are not included in sections in the CCR-CCD that are required for standard EHR documentation. If the email is "text only," then one might include any ad hoc information.
Oregon's Strategic Workgroup for the HIT Oversight Council
Yes

RedwoodMedNet


RelayHealth


Rhode Island Quality Institute


Secure Exchange Solutions


Social Security Administration


SureScripts


VA


VisionShare
Yes