Direct Project Compliance - Call for Consensus
Jump to navigation
Jump to search
Implementation Group Call for Consensus: Direct Project Compliance document
DUE: 3/28/11
Consensus voting on: Direct Project Compliance
Organization |
Endorsement (Yes or No) |
Comments (If "No," what can be changed to make it a "Yes") |
Disposition |
---|---|---|---|
ABILITY (formerly VisionShare) |
Yes |
||
Alere |
|||
Allscripts |
Yes |
||
American Academy of Family Physicians |
|||
Atlas Development |
|||
Avisena Inc. |
Yes |
||
Axolotl |
|||
CareEvolution, Inc. |
|||
CareSpark |
|||
Cautious Patient |
|||
Cerner Corporation |
Yes |
||
Christus Health |
|||
Clinical Groupware Collaborative |
Yes |
||
CMS |
|||
Covisint |
|||
CSC |
|||
DoD |
|||
eClinicalWorks |
|||
Emdeon |
|||
Epic |
|||
FEI |
|||
Health-ISP, a service of Garden State Health Systems |
Yes |
||
GE |
Yes |
As an informative specification this is useful. I have always had a problem calling this a compliance document, as the compliance document is the applicability statement. This is a guidance toward compliance. Or a guidance on deployment models toward compliance. |
|
Google |
|||
Greenway Medical Technologies |
|||
Harris Corporation |
Yes |
||
High Pine Associates |
|||
HLN Consulting, LLC |
Yes |
||
IBM |
|||
ICA |
|||
Indiana State Department of Health |
|||
Inpriva |
|||
Intel |
|||
Kryptiq |
|||
LabCorp |
|||
Massachusetts eHealth Collaborative |
|||
MedAllies |
No |
I think the backstop seems to be the spec that uses the SMTP backbone, etc. The enabling technology stuff is great and necessary, but this one sentence seems to have a circular reference that i think negates the enabling technologies stuff. Therefore I propose the following edit: "Similarly, when evaluating enabling technology, the simplest test to demonstrate Direct Project compliance is that the technology enables, for the users or other endpoints served by the technology, Direct Project-compliant transmission to and from other Direct Project-compliant addresses that are themselves served by technology implemented according to the Applicability Statement for Secure Health Transport' ." This might seem to rule out a network comprised entirely of enabling technology, but I think that a test of compliance would necessarily enjoin a some node that is accessible according to the referenced applicability statement. The ability to transact in a compliant manner (not actual end-to-end homogeneity in a given deployment) is what is being tested. |
|
MEDfx |
Yes |
||
Medical Informatics Engineering, Inc./ NoMoreClipboard.com |
|||
Medical University of SC, South Carolina Research Authority |
|||
Medicity |
|||
MedNet |
|||
MedPATH Networks |
|||
MedPlus/Quest Diagnostics |
Yes |
||
Microsoft |
|||
Mirth Corporation |
Yes |
||
Misys Open Source Solutions (MOSS) |
|||
MobileMD |
|||
NextGen Healthcare Information Systems, Inc. |
|||
NIH NCI |
|||
NIST |
|||
NYC Dept. of Health and Mental Hygiene’s PCIP |
|||
Oregon HIE Planning Team |
Yes |
||
Redwood MedNet |
|||
RelayHealth |
|||
Rhode Island Quality Institute |
Yes |
Agree with the MedAllies/Siemens caveats |
|
SAFE-BioPharma |
|||
SCHIEx - South Carolina Health Information Exchange |
|||
Secure Exchange Solutions |
|||
Serendipity Health, LLC |
Yes |
||
Siemens |
Yes with comment |
I agree w. the spirit of the document that the proof is in the pudding (sending from any Direct-compliant address to any other, whether through the pure Applicability Statement or through "enabling technology"). But I also get the point raised by MedAllies about what appears to be a "circular reference" that defines "Direct compliance" in terms of itself. So I am OK with MedAllies' proposed wording change, or a shorter version thereof. |
|
Surescripts |
|||
Techsant Technologies |
Yes |
||
TN State HIE |
|||
VA |
Yes |
||
Verizon Business |
Documentation and Testing Consensus Results Below
DO NOT MODIFY THIS TABLE -- For Reference Only
Workgroup Participant Organization |
Endorsement (Yes or No) |
Comments (If "No," what can be changed to make it a "Yes") |
---|---|---|
ABILITY (formerly VisionShare) |
Yes |
|
Akira Technologies, Inc. |
||
Alere |
||
Allscripts |
Yes |
with recommendation that we remove the phrase "that do not use Direct Project-compliant means for all local community exchange" |
American Academy of Family Physicians |
||
Atlas Development |
||
Axolotl |
||
CareSpark/Serendipity Health |
||
Cautious Patient |
||
Cerner |
||
Christus Health |
||
Clinical Groupware Collaborative |
||
CMS |
||
Covisint |
||
CSC |
||
DoD |
||
eClinicalWorks |
||
Emdeon |
||
Epic |
Yes |
With suggestion that we remove first person voice ("When I call you") |
FEI |
||
Garden State Health Systems |
Yes |
|
GE |
||
Google |
||
Greenway Medical Technologies |
||
Harris Corporation |
||
Healthcare Information Xchange of NY |
||
High Pine Associates |
||
HLN Consulting, LLC |
||
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 |
||
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 |
||
Others: |
||