Addressing Specification Implementation Group Endorsements

Company	Vote (Yes/No)	Comments
Allscripts	Yes
American Academy of Family Physicians
Axolotl
California Health and Human Service Agency
CareGroup/BIDMC
CareSpark
Cautious Patient
Cerner
CGI Federal
Clinical Groupware Collaborative
CSC	Yes
CSC Healthcare Group
eClinicalWorks
Epic
Gartner
GE	Yes	GE approves the 1.0 specification with the following comments that are intended to improve the readability and not intended to change the meaning: 1) Karen has made very constructive comments that should be fixed. I don't think that any of them are substantiate. 2) The first sentence of the abstract should be clear that this is scoped to the NHIN-Direct use-cases. Read out of context this could be understood as providing solution for use-cases that we didn't analize. 3) The second sentence of the abstract has no meaning. I recommend we remove it. 4) The third sentence of the abstract should also be specific to the 'point-to-point-push' aspect of these organizational use-cases. Surely we don't mean that this addressing specification solves all of the 'pharmacies' problems. I would rather this sentence simply reference the NHIN-Direct use-cases and not try to expand the scope unintentionally. 5) In the Purpose (and elsewhere), the term "IHE" is used to refer to specifically the "IHE XDS Profile" or sometimes "IHE XD* family of profiles". Given that IHE is a profiling organization with many domains (e.g., radiology, cardiology, quality, patient care, etc), I recommend that we spell out that we are referring to the "IHE XD* family of profiles" rather than just say "IHE". Where XD* means: XDS, XCA, XDM, and XDR; with their supporting infrastructure (See HITSP: SC112). 6) where XCA, XDS, and XDR are mentioned one should also mention XDM. 7) The 6th sentence begins "This standard provides...". The word "this" is ambigious. I think you mean "The NHIN-Direct Addressing Standard provides..." 8) Synopsis: The second sentence indicates that the Health Internet Address will 'provide a secure method of routing to the addressed recipient'. The 'addressing' specification provides 'addressing'. It does not provide security, delivery, or routing. Further the end of the sentence is confusing and is duplicate of the next sentence. I recommend the second sentence be: "The intent of the Health Internet Address is to provide an unambiguous endpoint identifier to enable the secure routing and delivery." 9) Given that we have picked an address format that looks like an email address format. I don't think that we should continue to include the examples of alternatives. This will only confuse the reader.
Healthcare Information Xchange of NY	Yes
HLN Consulting, LLC
IBM	No unless the suggested changes are applied	1) Fix broken links for IHE, NHIN standards, XCA, XDS, XDR and IHE metadata in section "Purpose". 2) The section "Purpose" should be changed to: This standard provides a standardized addressing mechanism supporting discovery of the HISP that routes or manages health information exchange on behalf of the individual origination point or endpoint of a health information exchange transaction. NHIN uses IHE standards XCA and XDR to transmit patient information between two health information organizations. XDR provides a metadata element to identify the intended recipient of the transmitted information. However, XDR places no requirements on how that metadata is to be used in making these routing decisions. The content of that metadata is flexible and must be interpreted according to policies established by the exchanging organzations 3) Replace last paragraph under Health Domain Name with the following: Organizations that manage Health Domain Names MUST maintain NHIN Direct HISP Address Directory entries for the Health Domain Name, as specified by the Abstract Model, and corresponding to rules established for concrete implementations of the Abstract Model. Organizations that manage Health Domain Names MUST ensure that at least one concrete implementation of the HISP to HISP abstract transaction is available for each Health Endpoint Name. Organizations may take on the HISP role or assign this function to another organization playing the HISP role. 4) Add the following text to the Security Considerations section: This section is a placeholder for future work.
Informatics Corporation of America
Kaiser
Massachusetts eHealth Collaborative	Yes
MedAllies
Medicity
MedPlus/Quest Diagnostics	Yes
Microsoft	Yes
Mirth Corporation	Yes
Mobile MD
NIST
NCI
Oracle
Oregon's Strategic Workgroup for the HIT Oversight Council	Yes
RedwoodMedNet
RelayHealth
Rhode Island Quality Institute
Secure Exchange Solutions
Social Security Administration
SureScripts	Yes
VA
VisionShare	Yes