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
  1. Personal pronouns ("I treat the Direct Project as a cloud") should be removed
  2. 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.
  3. 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 http://nhindirect.org/specifications+and+service+descriptions 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