Workgroup Call for Consensus: Applicability Statement for Secure Health Transport

Due: January 12, 2011

Consensus voting on: Applicability Statement for Secure Health Transport

This round of voting has closed. Vote here for the Implementation Group Consensus round.

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



Alere



Allscripts



American Academy of Family Physicians



Atlas Development



Axolotl



CareEvolution
Yes


CareSpark
Yes


Cautious Patient
Yes


Cerner Corporation
Yes


Christus Health



Clinical Groupware Collaborative



CMS



Covisint



CSC



DoD



eClinicalWorks



Emdeon



Epic
Yes


FEI



Garden State Health Systems
YES


GE
NO
a) Why is this not called “The Direct Project Specification”? Why are we trying to use a word that the healthcare industry is not familiar with (e.g. “Applicability Statement”)? Is this not the core specification?
b) The term “security user agent” is too closely tied to the reference implementation, a specific implementation of a specific deployment model. This is NOT a deployment model independent abstract term. I recommend against the term ‘agent’ as it is a term of architecture. Why not use the term “System”, as that is inclusive of all the Deployment Models which are different architectures to create a System that can produce/consume messages that are “Direct Project Specification” compliant. I would clearly be happy with “Actor”, but understand the aversion to anything IHE
c) The use of MTA and MUA are not known by too many people outside e-mail architects. At least spell them out. I really don’t think bring in these terms will be helpful.
d) The core specification should not include the “Service Model Security User Agent “. This is a specific implementation of the specification. It can certainly informatively point at the reference implementation models; but this is overly endorsing ONE model, and a model that requires Full Trust of a third-party allowing access to PHI and allowing them to impersonate the Sender.
e) The section on “Health Domain Name” should be more clear that this section is requiring MX records be maintained. This is a specific type of DNS record that I would agree is mandatory.
f) In the section on “Health Content Containers”
a. It is dangerous to provide alternative representations without a mechanism to indicate that they are both transforms of each-other. I recognize that this will happen, and don’t think we can or should forbid it. But we should encourage the use of XDM content packaging when this is desirable given that XDM does have mechanisms for relationships between documents as well as the index.htm that can be used by a receiver that doesn’t have XDM capable system
b. The parenthetical example of dedicated endpoint addresses for different content types is a useful process. Seems we could elevate this to a guideline document and not include it in a specification.
c. The statement about XDM is recommended for those that can… Why is this only recommended? Seems it should be required. Given that an XDM requires a receiver only be able to view a ZIP content, and INDEX.HTM; this is a low bar for a receiver.
a) This fits the definition 100% of an IETF applicability statement. Yes, it is the core specification.
b) The term "agent" has a long history and does not imply remote or separate processing, just application of the specified function on behalf of the user. An HTTP user agent (a browser) is not a remote piece of software, or is a Mail User Agent.
c) Spelled out -- these are SMTP terms of art
d) Disagree - people are trying to deploy these, and publishing specification and guidance is useful. Publishing it as an OPTIONAL section makes it clear, IMHO, that this deployment model is not required or implied by the specification
e) Done
f-a) I think this refers to something I already removed...
f-b) This addresses some of the policy concerns that have been raised, without unduly limiting technology
f-c) This is not a limitation on receivers, it's a recommendation for senders.
Google



Greenway Medical Technologies



Harris Corporation
Yes


Healthcare Information Xchange of NY



High Pine Associates



HLN Consulting, LLC



IBM
No - but getting really close
See my discussion post with detailed comments. In general, enormous improvement over prior version - well organized and clear.
Addressed as noted in that thread
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
Yes


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
Yes


Redwood MedNet



RelayHealth



Rhode Island Quality Institute



Secure Exchange Solutions



Serendipity Health, LLC
Yes


Siemens
Yes w comment
Suggest adding to the Abstract a statement such as this, to avoid implying that solutions already in place must be removed. "The scope of this specification is limited to the Security Agent feature (e.g., a collection of software modules) that claim conformance to the Applicability Statement for Secure Health Transport Direct specification. If such an agent is part of a larger system that also supports other capabilities in addition to Direct, such as alternative methods for exchanging or transporting information, those other capabilities are outside the scope of this specification, and such capabilities are not prohibited by the MUST NOT statements."
Addressed
SureScripts



Techsant Technologies
Yes


TN State HIE



VA



VisionShare
Yes