Implementation Group Call for Consensus: Direct Project Security Overview

Due 12/7/2010 based on second round of edits

Security and Trust WG Consensus Achieved: October 21st, 2010


Implementation Group Participant Organization
Endorsement (Yes or No)
Comments (If "No," what can be changed to make it a "Yes")
Akira Technologies, Inc.


Alere


Allscripts
Yes

American Academy of Family Physicians


Atlas Development


Axolotl


CareSpark/Serendipity Health
Yes

Cautious Patient


Cerner


Christus Health


Clinical Groupware Collaborative
Yes

CMS


Covisint
Yes

CSC


DoD


eClinicalWorks


Emdeon


Epic


FEI


Garden State Health Systems


GE
Yes
requested edits:
a) Section"Options for Enabling Trust". The text says that it 'considered'. I think the reader would better understand if we indicate that the direct project 'enables'. This is a more assertive statement of what we have delivered rather than simply what we considered.
b) Section "Risk Assessments" - Fourth bullet speaks of an "external HISP". We actually mean "Full Service HISP". This term is taking shape as something people understand as part of a deployment model where the HISP is fully trusted and assigned specific roles/responsibilities and risks.
c) Glossary -- The definitions under Certificate Authority and Digital Certificate are very complex, These need to be simplified. I am not sure why they need to be defined in a glossary when they are sufficiently defined in the text. (for example we never invoke an attribute certificate, and we specifically forbid the Web Browser Certificate Store.)
Google


Greenway Medical Technologies


Harris Corporation


Healthcare Information Xchange of NY


High Pine Associates
Yes

HLN Consulting


IBM


ICA


Inpriva


Intel


Kryptiq


Labcorp


Massachusetts eHealth Collaborative


MedAllies


Medical University of SC, South Carolina Research


Medical Informatics Engineering, (MIE)


Medicity


MedNET


MedPATH Networks


MedPlus/Quest Diagnostics


Microsoft
Yes

Mirth Corporation


Misys Open Source Solutions (MOSS)


NextGen Healthcare


NIH NCI


NIST


NoMoreClipboard.com


NYC Dept. of Health and Mental Hygiene's PCIP


Oracle Health Sciences Global Strategies


Oregon HIE Planning Team


Redwood MedNet


RelayHealth


Rhode Island Quality Institute


Secure Exchange Solutions


Siemens
Yes

SureScripts


Techsant Technologies
Yes

TN State HIE


VA


Verizon


VisionShare
Yes


Consensus voting on: Direct Project Security Overview

Workgroup Participant Organization
Endorsement (Yes or No)
Comments (If "No," what can be changed to make it a "Yes")
Akira Technologies, Inc.


Alere
Yes

Allscripts
No
Request for clarifications to the document:
  • How circles of trust are administered (technically)

  • How the sender knows (technically) if the recipient/peer is in a particular circle - namely one which the sender has joined.
  • That not all certificates issued by a particular CA are in a circle of trust (ambiguous in the current document)
American Academy of Family Physicians


Atlas Development


Axolotl


CareSpark/Serendipity Health


Cautious Patient


Cerner


Christus Health


Clinical Groupware Collaborative
Yes

CMS


Covisint
Yes

CSC


DoD


eClinicalWorks


Emdeon


Epic
No
Show stoppers:
1. MedAllies comment, below.
2. Document must be clarified to remove the notion that the Direct Project stipulates that individual users (humans) must be able to elect to participate in certain trust circles, or to trust certain senders or recipients. In some implementations, this decision might not be made by individual users, and the document seems to imply that this is a Direct Project requirement.
Other suggestions:
1. I made a few changes for style, spelling, etc - see document history
2. The PHR example isn't a good one - Direct Project doesn't cover receiving messages from an individual via PHR right now.
3. Is TLS not required? Right now, we say that the Direct Project "encourages" it?
4. "The Direct Project committee" should be clarified (and hyperlinked, if possible). The Implementation Group? The S&T WG?
FEI


Garden State Health Systems


GE


Google


Greenway Medical Technologies


Harris Corporation


Healthcare Information Xchange of NY


High Pine Associates
Yes

HLN Consulting
Yes
The Decentralized Trust Model section deserves more detail, either in this document or in another document. For example, what trust decisions may/should be made by individual users versus their organizations or their HISPs, how those decisions will be made, and the impact of those decisions on message delivery.
IBM


ICA


Inpriva
No
It is unclear who is responsible for identity proofing and assurance of the user. Is it the responsibility of the CA? Or is it reflected in the terms and conditions of the digital certificate that the CA must “enforce” with respect to the user? It is the user who will be faced with determining whom to trust based on the diverse policies that apply to the Direct Project endpoints. How will this approach scale as the number of Direct communities proliferate?
Intel


Kryptiq


Labcorp


Massachusetts eHealth Collaborative


MedAllies
No
change of statement in section called "Protecting Information Exchange" that says, "The Direct Project solution mandates the use of S/MIME as the means to provide end-to-end authenticity, confidentiality and integrity protection." This doesn't seem to accommodate the XDD path toward accomplishing NHIN-D.
Medical University of SC, South Carolina Research


Medical Informatics Engineering, (MIE)
Yes

Medicity


MedNET


MedPATH Networks


MedPlus/Quest Diagnostics


Microsoft
Yes

Mirth Corporation


Misys Open Source Solutions (MOSS)


NextGen Healthcare
No
Joining MedAllies comment: It covers S/MIME, but not the XDR transport
Joining Epics comment: transport encryption is recommended, it probably should be required
Message Encryption: The message is required to be encrypted. How does this transpose for XD*?
Message Integrity: The message is required to be signed. How does this transpose for XD*?
NIH NCI


NIST


NoMoreClipboard.com


NYC Dept. of Health and Mental Hygiene's PCIP


Oracle Health Sciences Global Strategies


Oregon HIE Planning Team
Yes

Redwood MedNet


RelayHealth


Rhode Island Quality Institute


Secure Exchange Solutions


Siemens
Yes

SureScripts


Techsant Technologies
Yes

TN State HIE


VA


VisionShare
Yes
Depending on the reader, the term PHI may not be well understood. Defining that acronym may be useful.
We do not agree with other comments that transport encryption (SSL/TLS) should be required. The payload for the SMTP backbone is already S/MIME signed and encrypted so why should transport encryption be required? It would complicate the simple and secure SMTP interoperability that is already working between candidate HISPs.