Applicability Statement for Secure Health Transport - Call for Consensus

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