Evaluation Criteria for Trust Anchors and Certification Authorities - IG Consensus
Jump to navigation
Jump to search
Implementation Group Call for Consensus: Evaluation Criteria for Trust Anchors and Certification Authorities
DUE: 3/15/2011
Please Review: Evaluation Criteria for Trust Anchors and Certification Authorities
Organization |
Endorsement (Yes or No) |
Comments (If "No," what can be changed to make it a "Yes") |
Disposition |
ABILITY (formerly VisionShare) |
Yes |
||
Alere |
|||
Allscripts |
|||
American Academy of Family Physicians |
|||
Atlas Development |
|||
Avisena Inc. |
Yes |
||
Axolotl |
|||
CareEvolution, Inc. |
|||
CareSpark |
|||
Cautious Patient |
|||
Cerner Corporation |
Yes |
||
Christus Health |
|||
Clinical Groupware Collaborative |
|||
CMS |
|||
Covisint |
|||
CSC |
|||
DoD |
|||
eClinicalWorks |
|||
Emdeon |
|||
Epic |
No |
We do not agree with the line: "Denial of prospective trust anchors must be based on these criteria and denials should be accompanied by the criterion violation that triggered the denial. Denial should not be based on subjective criteria, or on criteria not associated with protecting privacy, security and trust." Organizations may have other valid reasons to choose not to accept a particular trust anchor. |
|
FEI |
|||
Health-ISP, a service of Garden State Health Systems |
Yes |
||
GE |
|||
Google |
|||
Greenway Medical Technologies |
|||
Harris Corporation |
|||
High Pine Associates |
|||
HLN Consulting, LLC |
|||
IBM |
|||
ICA |
|||
Indiana State Department of Health |
|||
Inpriva |
|||
Intel |
|||
Kryptiq |
|||
LabCorp |
|||
Massachusetts eHealth Collaborative |
|||
MaxMD |
|||
MedAllies |
|||
MEDfx |
Yes |
||
Medical Informatics Engineering, Inc./ NoMoreClipboard.com |
|||
Medical University of SC, South Carolina Research Authority |
|||
Medicity |
|||
MedNet |
|||
MedPATH Networks |
|||
MedPlus/Quest Diagnostics |
Yes |
||
Microsoft |
|||
Mirth Corporation |
Yes |
||
Misys Open Source Solutions (MOSS) |
|||
MobileMD |
|||
NextGen Healthcare Information Systems, Inc. |
|||
NIH NCI |
|||
NIST |
|||
NYC Dept. of Health and Mental Hygiene’s PCIP |
|||
Oregon HIE Planning Team |
Yes |
Agree with EPIC and Siemens comments on wording for accepting trust anchor |
|
Redwood MedNet |
|||
RelayHealth |
|||
Rhode Island Quality Institute |
|||
SAFE-BioPharma |
|||
SCHIEx - South Carolina Health Information Exchange |
|||
Secure Exchange Solutions |
|||
Serendipity Health, LLC |
|||
Siemens |
Yes |
Wording suggestion: there may be some confusion engendered when the word "must" is used often, yet this is not a normative spec but a "best practices" document. Epic's comment seems affected by the "must be based" part of the sentence, whereas the last part of the sentence uses the word "should not be based on subjective criteria..." Nevertheless, substantively we can endorse this document. |
|
Surescripts |
|||
Techsant Technologies |
|||
TN State HIE |
|||
VA |
|||
Verizon Business |
Yes |
With a few notes - 1. It might be of value to share well served to discuss some of this with the FPKI PA at some level. 2. The concept of a RPS allows the delegation of Identity Proofing to the organization that is getting the certificates (a Trusted Agent). This makes it the participant responsible for identity proofing their employees and limits any liability that we as the CA has. And limit the audit requirements between parties. 3.EV SSL is not relevant beyond the EV SSL certificate and identifying the EE for certificates and that should be treated as separately. |