Direct Project Security Overview - IG Call for Consensus

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.