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.


Need to better explain/address the concerns (raised in the previous round by Siemens and HLN)
about requiring a separate e-mail client. Yes it is more secure, but how is this practical?
Unless I misunderstand, it implies that every organization must install a new e-mail client,
regardless of whether they already have a secure S/MIME e-mail client that may already
be sending secure messages. (I have one, for example). So if you're using Outlook, you can't
use it and have to find something else for Direct?
Also, please see the question posed at this discussion tab
http://nhindirect.org/message/view/Certificate+Pilot+Recommendations+Discussion/30623699
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