Certificate Pilot Recommendations Call for Consensus
Jump to navigation
Jump to search
Implementation Group Call for Consensus: Certificate Pilot Recommendations
- Implementation WG: Completed (01/20/2011)
- Best Practices WG: Completed (10/12/2010)
- ===Implementation Geographies WG: Completed (10/20/2010)===
- ===Security and Trust WG: Completed (11/18/2010)===
Completed 01/20/2011. VOTING IS NOW CLOSED.
| Implementation Group Participant Organization |
Endorsement (Yes or No) |
If No, what can be changed to make it Yes? |
| Akira Technologies, Inc |
||
| Alere |
||
| Allscripts |
Yes |
|
| American Academy of Family Physicians |
||
| Atlas Development |
||
| Axolotl |
||
| CareEvolution |
Yes |
|
| CareSpark |
Yes |
|
| Cerner |
Yes w/ comment |
On the topic of expectation for an LDAP option for public certificate discovery, we suggest waiting for forthcoming HITSC recommendations on "provider directories" which will almost certainly contain an LDAP-based certificate discovery model. No need for us to invent yet another new cert discovery mechanism. |
| Christus Health |
||
| Clinical Groupware Collaborative |
||
| CMS |
||
| Covisint |
||
| CSC |
||
| DoD |
||
| eClinicalWorks |
||
| Emdeon |
||
| Epic |
||
| FEI |
||
| Garden State Health Systems |
Yes |
|
| GE |
Yes w/ comment |
a) There are statements about the "Intent" of the "Direct team" to specify a single discover mechanism. I disagree that this is or should be our intent. Our intend is to deliver a specification for delivering content, not for universal certificate discovery. b) The text includes language around "private certificates". This is NOT correct language. A private KEY is a private key and shall always be kept private, or the certificate must be revoked. A certificate is a PUBLIC object and does not need to be protected in any way. The use of 'private certificate' is WRONG. c) Question 1 -- There should be no restriction on the flow of certificates. There should be restriction on the act of 'trusting' any specific 'trust anchor'. d) Question 1 -- The final sentence speaks of 'being aware of the specific requirements for the Federal agencies". What does it mean to be aware of them? What does one need to do with this awareness? How would this awareness affect things? I think this should be expanded or removed. Federal partners already are aware of it because they must be aware of it. Those that don't need to be aware of it, will simply be confused or ignore the text. e) Question 2 -- the example of organizational endpoint is incorrect. All Direct endpoints must be of the email form. Thus better examples would be "Lisa@hospital.com" vs "all@hospital.com". Or are you describing a Certificate scope that says all endpoint addresses at hospital.com? Meaning *@hospital.com? This is confusing as the terminology is not consistent with other "Direct Project" text. f) Question 2 - confusing and unnecessary phrase "The reference implementations do not manage private certificates --- they merely allow administrators to associate certificates with endpoints and domains. " g) Question 2 - Recommendation (a) is a good recommendation that speaks more broadly to certificate issuance, not necessarily a choice about organizational or end-user certificates. This section seems to be more about recommendations on certificate issuance. Yet there is no option (c) which is to use only one certificate for all endpoint addresses at an organization. h) Question 2 - I can't understand recommendation (b). What is a 'signing certificate'? This document needs to be harmonized with formal terms i) Question 3 -- another solution not listed... Pick up the phone and call the organization and ask questions. The old ways still work during the provisioning step. Note also that this provisioning step is usually FULL of lots of legal documents too. Have the lawyers involved. j) Question 4 -- what is a 'private address certificate'? And why must it be manually refreshed? I suspect you are talking about individual certificates that have been manually trusted rather than trusted because of a chain to a trust-root? This has not been discussed earlier in the paper, so it should not be brought in here. k) Organization policies -- it is confusing to have yet another set of questions 1-4... sequence or sub-number. l) question 3 AND 4 -- I understand the guidance, but I don't see how this is really going to solve the problem. this is simply an effort to make it look like the issue is being addressed (aka security theater). It is not uncommon for mature organizations to have outbound email filtering that stops 'leakage' by looking for typical text/phrase patterns. Better to recommend something this. Or to recommend Directed messages be integrated into the EHR so that never is a common email package being used. m) |
| Google |
||
| Greenway Medical Technologies |
Yes |
|
| GSI Health |
Yes |
|
| Harris Corporation |
Yes |
|
| Healthcare Information Xchange of NY |
||
| High Pine Associates |
Yes |
|
| HLN Consulting, LLC |
||
| IBM |
Yes |
|
| ICA |
||
| Inpriva |
||
| Intel |
||
| Kryptiq |
||
| LabCorp |
||
| Massachusetts eHealth Collaborative |
||
| MedAllies |
Yes |
|
| Medical University of SC, South Carolina Rese |
||
| Medical Informatics Engineering, Inc. |
||
| Medicity |
||
| MedNET |
||
| MedPATH Networks |
||
| MedPlus/Quest Diagnostics |
Yes |
|
| Microsoft |
Yes |
|
| Mirth Corporation |
||
| Misys Open Source Solutions (MOSS) |
||
| MobileMD |
Yes |
|
| 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 |
||
| Serendipity Health, LLC |
Yes |
|
| Siemens |
YES (as of Jan. 11th 2011) No |
Our comments below were addressed. I think that this table should have been cleaned out to separate last round's comments from the January 12th round. |
| Surescripts |
||
| Techsant Technologies |
Yes |
|
| TN State HIE |
||
| VA |
||
| Verizon |
||
| VisionShare |
Yes |
Deadlines:
Consensus voting on: Certificate Pilot Recommendations.
| Workgroup Participant Organization |
Endorsement (Yes or No) |
If No, what can be changed to make it Yes? |
| Akira Technologies, Inc |
||
| Alere |
||
| Allscripts |
Yes |
|
| American Academy of Family Physicians |
||
| Atlas Development |
||
| Axolotl |
||
| CareSpark/Serendipity Health |
Yes |
|
| Cerner |
||
| Christus Health |
||
| Clinical Groupware Collaborative |
Yes |
|
| CMS |
||
| Covisint |
||
| CSC |
||
| DoD |
||
| eClinicalWorks |
||
| Emdeon |
||
| Epic |
||
| FEI |
||
| Garden State Health Systems |
Yes |
|
| GE |
||
| Google |
||
| Greenway Medical Technologies |
||
| GSI Health |
Yes |
|
| Harris Corporation |
||
| Healthcare Information Xchange of NY |
||
| High Pine Associates |
Yes |
Not keen about using separate domains and email clients - will not scale in provider settings |
| HLN Consulting, LLC |
Yes |
|
| IBM |
Yes |
|
| ICA |
||
| Inpriva |
Yes |
Question #1 Pilot Recommendation: Ok for pilot but concerned that this approach will not scale well. |
| Intel |
||
| Kryptiq |
||
| LabCorp |
||
| Massachusetts eHealth Collaborative |
||
| MedAllies |
Yes |
|
| Medical University of SC, South Carolina Rese |
||
| Medical Informatics Engineering, Inc. |
Yes |
|
| Medicity |
||
| MedNET |
||
| MedPATH Networks |
||
| MedPlus/Quest Diagnostics |
Yes |
|
| Microsoft |
Yes |
|
| Mirth Corporation |
||
| Misys Open Source Solutions (MOSS) |
||
| MobileMD |
Yes |
|
| NextGen Healthcare Information Systems, Inc. |
||
| NIH NCI |
||
| NIST |
||
| NoMoreClipboard.com |
||
| NYC Dept. of Health and Mental Hygiene’s PCIP |
||
| Oregon HIE Planning Team |
Yes |
Still have some concerns about scalability |
| Redwood MedNet |
some issues |
[1] -- either i don't understand their usage, or i propose a revision in the definitions of community, organization & implementation as follows, for clarity: COMMUNITY = a group of organizations that agree to a common set of policies to establish directed message exchange <insert one word> ORGANIZATION = an entity that collects together one or more endpoints. Generally corresponds to a HIPAA covered entity (and any contracted BAs) <unchanged> IMPLEMENTATION = a deployment of NHIN Direct technology by an Organization to deliver messaging functionality to an organization a Community <major edits to clarify meaning> [2] -- mis-used word in "Overview of Community Policy Decisions." -- "Please note that the term trust in this document requires refers specifically to the trust enabling..." [3] -- Redwood MedNet (capital N) is mis-spelled with a lower case n (Mednet) in "Question #1: Who is the Trust Anchor for the Community?" |
| RelayHealth |
||
| Rhode Island Quality Institute |
Yes |
|
| Secure Exchange Solutions |
||
| Siemens |
Unsure |
Concerned about the implications of "Pilot Recommendation: Minimize the potential for human error by using a special purpose mail client for Direct messaging" While that will simplify things for pilot, is it believed that recommendation would be acceptable in the real world? Sounds like it's saying everyone should install a new e-mail client other than what they use, even if their current client is completely secure and conformant. Won't that be a barrier to entry? Also, though this is not a standard or specification, I suggest making consistent the use of "must/should/may" all of which occur in the text and might be interpreted as if it were a spec. |
| Surescripts |
||
| Techsant Technologies |
Yes |
|
| TN State HIE |
||
| VA |
||
| VisionShare |
Yes |