Query+Health+Transport+Analysis

include component="page" wikiName="siframework" page="Query Health Header"



This wiki page will facilitate the analysis of the various Transport approaches used in the summer concert series and NwHIN to determine the best approach for Query Health.

Notes on Direct Transport option from F2F: [|20111018 SPN Direct Transport for QH Notes.pptx]
 * **Transport Analysis Feature** || **DIRECT (SMTP)** || **SOAP WS** || **RESTful WS** ||
 * Ability to setup multiple networks and allow participants to participate in multiple networks || The Direct "trust anchor" model was created specifically to address this exact issue of a single user/address participating in multiple logical networks. Because addressing is universal, it is a simple matter of configuration to add/remove participants. || SOAP WS supports a range of security and trust models through many established profiles: WS-Security, WS-Trust, WS-Federation...

It allows use of existing technologies such as X.509 public-key certificates, XML-based tokens, Kerberos shared-secret tickets, and even password digests. It supports identity-based authorization, access control lists, and capabilities-based authorization. || Supported, exact mechanism depends on technology used .E.g. use of mutual SSL would be equivalent to Direct. Use of OAuth 2 would require trust of a network-specific authorization server. In either case it is a simple matter of configuration. ||
 * Ease of setup as partners join and quit the network || Adding a new participant involves issuing a new certificate and adding a Direct address to a standard mailing distribution list. Participants can be removed by removing them from the mailing list and adding the relevant certificate to the organization's revocation list. Both of these are, again, configuration-only actions. || Similar to the Direct model, for a new partner to join the network, the process can just involve issuing a new certificate and adding a new end point to the recipient list. The end point can be integrated with the query network. No separate linkage from a mail inbox will be required. Certificate revocation can be used to remove participants from the network. || For mutual SSL, adding a new participant requires issuing a new certificate. For OAuth 2 a new account would need to be established on the network authorization server. ||
 * Support for Asynchronous Transactions || SMTP is by definition an asynchronous protocol. It supports extremely rich retry mechanisms and is resilient to transient network or server downtime. In a world where we are querying hundreds or thousands of participants --- such downtime will be a regular occurrence and if we don't pick a protocol that natively handles it, we'll have to build it ourselves. Nasty. || SOAP WS fully supports asynchronous transactions through the use of many well-established profiles: WS-Addressing, WS-ReliableMessaging, WS-ReliableMessaging Policy, WS-SecureConversation, ... || HTTP is inherently request-response. Common mechanisms exist for managing long running actions asynchronously. E.g. the 202 Accepted status indicates that a request was accepted and is pending and typically contains a Location URI that can be polled for results. Also, mechanisms such as PubSubHubbub, long-polling (COMET), short polling. ||
 * Loose Coupling between Transport layer and other layers like authorization and query execution || Direct is purely a transport mechanism. It moves payloads in standard MIME format. The query execution engine will be implemented in completely separate code as a standard SMTP "autoresponder". Off-the-shelf, open source packages like Apache James are built to do this already. Both Direct production implementaitons (Java and .NET) also include a plug-in model that allows loosely-coupled code to be executed when messages arrive for particular addresses.

Direct does include a built-in "edge" authorization mechanism (the "trust anchor" model discussed above). This is an advantage for basic segmentation of query networks. Additoinal granular authorization can be implemented in the autoresponder layer completely independently from the transport layer.

We have already seen the flexibility of the Direct model in separating transport from content --- for example, CCR and CCD documents are often sent over the protocol, as well as HL7 messages, binary images and files, etc. --- the transport is constructured for exactly this kind of separation and includes all the necessary mechanisms for recipients to decide if they are interested in / able to respond to inbound messages. || SOAP WS supports both synchronous and asynchronous transaction. The transport layer and the other layers can be loosely coupled, especially in the case of asynchronous transactions. Authorization decisions, which can be based on security artifacts in SOAP header (e.g. SAML, authentication statement, authorization statement, ..), and/or other data in the SOAP body, can implemented many ways at different points of the service life cycle. Delivery of the service quest (query) via SOAP transport is not tied to an automatic execution of the query. The responder agent has full control on the fulfillment of the service quest. || While its possible to use HTTP purely as a transport, doing so negates many benefits of the protocol. True RESTful WS require use of hypertext to drive applications. For opaque message payloads, the HTTP Link header can be used to carry such hypertext.

HTTP offers an extensible header mechanism that is commonly used to layer in additional functionality including authorization schemes like OAuth 2. ||
 * Ability to support multiple query types and formats || See above with respect to MIME-based message formats. We can use a combination of MIME types and other structured metadata to represent query types and formats, and these can be inspected by recipients as part of the workflow of deciding if they are able and willing to respond. || SOAP can be used to carry any data format, along with structured meta data that are enforceable through the use of published schema. || HTTP is MIME based so can be used to carry any data format. ||
 * Are the approaches leveraging NwHIN (Are they part of NwHIN) || Direct is an official supported transport of the NwHIN. || NwHIN Connect is SOAP based and many components can be leveraged: e.g., authorization framework, subscribe and notification transaction (HIEM). || No. ||
 * Reliability of approach to addressed distributed participants, network failures and the asynchronous request/responses || As discussed above, SMTP is by design an asynchronous protocol that expects network and server instability. Retry logic is built in, as are MDN responses back to recipients so that they can know when messages have been accepted. From this perspective, Direct/SMTP gives us enormous advantage.

The one area where SMTP is not perfect here is that there is no guarantee of a response. This means that queries will have to implement some reasonable timeout (in terms of days/weeks) to receive responses back. Realistically, this will be similar with other transports --- except they will have to implement it with complex retry logic that they manage state around. || Profiles like WS-Addressing, WS-ReliableMessaging, WS-Reliability are designed to deal with asynchronous request/responses over distributed networks that may fail. || As discussed above, there are common patterns for using HTTP with long-running asynchronous operations. HTTP semantics nicely separate operations that change server state from those that don't, this allows idempotent operations (e.g. using GET to poll for status) to be optimized.

Identifying submitted queries with URIs would allow for their status to be tracked, errors to be monitored and results retrieved. ||
 * Security Model for Identification/Trust and extensions for Authorization || The trust circle model affords excellent "edge-level" protection to ensure that only authorized members of a query network can talk over that network. Additional authorization woudl be defined with metadata in the message and can be interpreted/enforced as desired. || SOAP offers support for the most variety of established security models. Authentication, authorizations artifacts can be carried in SOAP headers to enable the receiving system to establish identification/trust and make authorization decisions. || Using mutual SSL would afford the same level of go/no-go protection as per DIRECT. Using OAuth 2 would allow additional levels of authorization based on token types, e.g. different types of token might grant access to different sets of patient data. ||
 * Use in existing networks (i2B2, hQuery, PopMedNet) || Direct is NOT used in any of the summer concert series mechanisms we saw --- it is just coming into production use. However, we are seeing multiple "autoresponder" use cases emerge in the real world already. || ? (Not familiar with the 3 networks, can some one fill this in?) || RESTful WS are used in hQuery. hQuery uses a publish/subscribe approach based on hData (HTTP+Atom) for a managing query submission, status monitoring and result retrieval. ||
 * Does the approach impose new infrastructure requirements like new ports to be opened on firewalls, new software to be installed || Most healthcare institutions and HIEs are currently investigating how to deploy Direct messaging for their participants. This can be done as a new software installation, as an addition to existing email services, or as a hosted service from providers such as SureScripts. Assuming that activity proceeds, using Direct for Query Health would require no additional hardware or open ports --- the existing messaging infrasturcture can be reused in total.

If no Direct capability exists, it will have to be installed for Query Heath. This does involve answering requests for SMTP and DNS. Again, most systems will have already opened these ports for traditional messaging and those systems can be reused. || HTTPs are typically supported already by health care institutions and HIEs. To support Query Health, new software for Query Health will need to be installed. But that will be true regardless of the transport layer we use. No aditional plug-ins into existing features, such as SMTP servers to link that with the Query Health components, will be required. || The approach requires the common HTTP and/or HTTPS port to be open. In addition the Web server will need to be configured to forward requests to a URI subtree to an installation of the gateway software. ||
 * Does the approach require centralized infrastructure of some sort || No; use of DNS as an addressing mechanism avoids the need for new centralized infrastructure. The "distributor" role does need to support one or more distribution lists per query network. || The requester agent needs to know the end points of responder agents in the network, similar to knowing the recipient in a mailing list. Requirements on certificate management is the same for all 3 transport methods. || Not required but likely there will be some kind of per-network infrastructure. E.g. cert infrastructure for mutual SSL or an OAuth 2 authorization server for OAuth 2. ||

include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"