Applicability Statement for Secure Health Transport - Call to Consensus on Requiring DNS and LDAP Certificate Discovery

Implementation Group Committed Organizations Call for Consensus: Updates to Applicability Statement for Secure Health Transport v1.0 to Require DNS+LDAP for Certificate Discovery

Closed, consensus reached on 07/09/2012.

Consensus voting on: Updates to Applicability Statement for Secure Health Transport v1.0 Requiring DNS and LDAP for Certificate Discovery

Consensus Process

Each Direct Project committed organization may provide one vote or abstain from voting. Votes may be:
 

• Yes
  • A yes vote does not necessarily mean the deliverable is ideal but that it is better to move forward than block it
  • Comments may be provided for consideration
• No
  • A no vote must be accompanied by comments that detail why the vote is no and what steps can be taken to address concerns
  • A no vote without comments is counted as an abstention

The updates detailed in the Updates to Applicability Statement for Secure Health Transport v1.0 Requiring DNS and LDAP for Certificate Discovery will be applied to the Applicability Statement for Secure Health Transport after consensus.


If you belong to a committed organization and do not see your organization listed below, please add it.

Organization	Endorsement (Yes or No)	Comments (If "No", what can be changed to make it a "Yes")	Disposition
ABILITY Network, Inc.	Yes
Alere
Allscripts
American Academy of Family Physicians
Atlas Development	Yes
IOS Health Systems
Axolotl
CareEvolution, Inc.
Cautious Patient
Cerner Corporation	Yes
Christus Health
Clinical Groupware Collaborative
CMS
Covisint
CSC
DoD
Dossia
eClinicalWorks
Emdeon
Epic
FEI
Health-ISP, a service of Garden State Health Systems
GE	Abstain with Comment	I would have expected that the STA be allowed to choose either method (or both for more robust value-add), and you would then place the requirement on Certificate Publishers to publish in both methods. This would allow for more consistent deployment and spread the burden more to the publishers of certificates. Where the publishers of certificates are far more likely to be able to take on the burden than are the much more numerous STA. This would also have not invalidated all existing STA, which the change proposed will do.	Thanks for your comments. An additional method beyond DNS was required to address certain publication challenges (e.g., some DNS servers prevalent in the market do not support CERT records). These challenges would remain for publishers if publication using both methods were required. More on the reasoning behind the DNS+LDAP approach can be found in the Certificate Discovery for Direct Project Implementation Guide.
Google
Greenway Medical Technologies
Harris Corporation
High Pine Associates
HLN Consulting, LLC
IBM
ICA
Indiana State Department of Health
Inpriva	Yes
Intel
Kryptiq	Yes
LabCorp
Massachusetts eHealth Collaborative
MaxMD
MedAllies
MEDfx
Medical Informatics Engineering, Inc./NoMoreClipboard.com
Medical University of SC, South Carolina Research Authority
Medicity
MedNet
MedPATH Networks
MedPlus/Quest Diagnostics
Microsoft	Yes
Mirth Corporation
Misys Open Source Solutions (MOSS)
MobileMD
NextGen Healthcare Information Systems, Inc.
NIH NCI
NIST
NYC Dept. of Health and Mental Hygiene’s PCIP
Optum.com
Oregon HIE Planning Team	Yes
Redwood MedNet
RelayHealth
Rhode Island Quality Institute
SAFE-BioPharma
SCHIEx - South Carolina Health Information Exchange
Secure Exchange Solutions
Serendipity Health, LLC
Siemens
Surescripts
Techsant Technologies	Yes with comments.	The Direct software must implement DNS and LDAP discoverability but with the flexibility of controlling the features using a configuration setting. Such that, If an organizational policy is not to enable the discoverablilty the settings can be turned off allowing the software to still exchange the certificates out of band.
TN State HIE
VA
Verizon Business
Wellogic