Deployment Models Overview - Call for Consensus

Implementation Group Call for Consensus: Deployment Models

DUE: December 23, 2010

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
CareSpark/Serendipity Health	Yes, with comments	While we understand the need for a high level document for deployment models, I feel this could be improved with more information as the pilot geographies continue preparing for the demonstration at HIMSS. If the document is release prior to HIMSS, we should take down a task to manage among groups by some facilitated fashion the review and update of the document by March or April 2011 to ensure more adoption across the nation.	Agree - All documents in The Direct Project are open to revision as more information comes to light. No Change
Cautious Patient
Cerner
Christus Health
Clinical Groupware Collaborative
CMS
Covisint
CSC
DoD
eClinicalWorks
Emdeon
Epic		Can you change your deployment document to reflect the "new" diagrams? It is important for the sending HISP to be able to do the routing without having to do SMTP, if hte recipient is XDR.	The goal of the Deployment Models is to show use of "The Direct Project" specification/ The 'super-HISP' that has some internal pathways that never use "The Direct Project" specification is simply not using "The Direct Project" specification for those pathways. That pathway can't be called "The Direct Project" compliant. This is not to say that this is an invalid software/system architecture; but we can not document software/system architectures. No change
FEI
Garden State Health Systems
GE	YES
Google
Greenway Medical Technologies
Harris Corporation	No	No issue with current content, but suggest additional content. Discussions between the .NET and Java XD groups have identified additional deployment models which should be mentioned in section E (Direct Project to/from XDR). E.1 depicts the scenario where a destination HISP is the responsible party for routing and forwarding to an XDR endpoint. It is also possible that the originating HISP may be responsible for the routing. In this case, the message would not enter as S/MIME, requiring only a transformation and forward to a mapped endpoint (XDR + TLS). See the first image on http://wiki.directproject.org/Java+XD*+Architecture which points out the additional flow. E.2 depicts the case where a HISP will be receiving XDR and forwarding as S/MIME to a remote HISP. There is also the scenario where the HISP receiving XDR may handle the mail locally. This will only require a simple transformation to XDM. See the third image on http://wiki.directproject.org/Java+XD*+Architecture which points out the additional flow.	The goal of the Deployment Models is to show use of "The Direct Project" specification/ The 'super-HISP' that has some internal pathways that never use "The Direct Project" specification is simply not using "The Direct Project" specification for those pathways. That pathway can't be called "The Direct Project" compliant. This is not to say that this is an invalid software/system architecture; but we can not document software/system architectures. As far as I can tell, the dashed line in your 'java architectures is an XDR transaction? This is a great solution architecture, but this pathway is not using "The Direct Project" specification. It is still a very useful solution, meeting the high-level use-cases. It is simply not "The Direct Project" compliant. We need to be clear what is formal documentation, and what is 'reference implementation'. I am very worried that the suggestion given here would result in NON-CONSENSUS specification; but rather force the reference-implementations as the specification. No change
Healthcare Information Xchange of NY
High Pine Associates
HLN Consulting, LLC	Yes with minor comments	Personal pronouns ("I treat the Direct Project as a cloud") should be removed Oval in diagrams A-D should be modified for clarity: "Document or XDM" should be "Message, Document or XDM" so as to not allow the reader to think HL7 V2 messages, for instance, are not permitted or even likely. Section E has to be sanitized for "NHIN" acronym------> Note: Comments addressed	Comments addressed in first round
IBM	Yes
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	Yes
Redwood MedNet
RelayHealth
Rhode Island Quality Institute
Secure Exchange Solutions
Serendipity Health, LLC	Yes, with comments	While we understand the need for a high level document for deployment models, I feel this could be improved with more information as the pilot geographies continue preparing for the demonstration at HIMSS. If the document is release prior to HIMSS, we should take down a task to manage among groups by some facilitated fashion the review and update of the document by March or April 2011 to ensure more adoption across the nation.	DUPLICATE: Serendipity Health has already registered the same vote above.
Siemens	Yes, with comments	Introduction, Deployment Option A: suggest "to an external service" rather than "to a cloud based service" since the location of the HISP might not necessarily be in the cloud. Could be another service within an intranet, for example. Also, re the statement "All normal Direct Project assumptions .... are in play." How do we distinguish "normal" from "abnormal" assumptions? Since all deployment models make the same statement, I suggest dropping the word "normal" altogether. In the MIXING AND MATCHING section: Is the phrase "common Direct Project specification" understood? There are lots of specifications within the Direct Project. If you're referring to the other spec (Simple Health Transport) currently up for consensus, then include a link to that. If you're referring to the overall "set" of specs (and what comprises that set, exactly?), then there should be a page where we list all the approved specifications in that set. MAYBE the following page is up-to-date and defines that set [1] All I know is that many specifications (e.g., addressing, content container, etc.) have existed and been approved at some level over the past few months. Under TASKS -- Sending, it says 6. Sending the S/MIME message via SMTP using TLS, as if that's required for everyone. But later, in describing Options B and D, it says that TLS is "not mandated between client and HISP" so is there an inconsistency between those statements? Option E introduction as well as E.1 and E.2, where it includes several link to "XD* Conversions for Direct Messaging" The page is still there, but the title has changed to "XDR and XDM for Direct Messaging" so please use that title instead. ----> Note: Comments addressed	Comments addressed in first round
SureScripts
Techsant Technologies
TN State HIE
VA
VisionShare	Changed No to Yes after changes in Disposition section	Major issue (our reason for the "no" vote): The document skips an alternative to option D: An EHR/PHR without integrated S/MIME functionality. Item D describes a sophisticated EHR/PHR that embeds security agent and routing functionality. There needs to be an item showing an EHR/PHR using a full-service HISP through a secure REST or SOAP API. Smaller vendors (and even some larger vendors) will choose this model. Two other issues: Item A: The last sentence ends with "to an external internet based service". The phrase "internet based" may give the impression that the HISP email server is accessible only over the internet. This is not necessarily the case. The HISP SMTP/POP3 server could be (and will be in certain cases I am aware of) located behind the provider's firewall. Change to "to an external (possibly internet based) service". Item C: This phrase should be changed: "internet service provider is fully trusted and responsible". The term "internet service provider" should be changed to "HISP" or "information service provider" to match Direct terminology.	Updated "C" introduction to include REST and SOAP api Removed the word "internet based" Fixed wording on trusted