User Story Implementation Group Endorsements

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