Concrete Model Comparison

​​This table presents a comparison of the four Concrete Implementions based on a list of criteria.

The table is not in priority order, there is no agreement regarding which criteria is highest or lowest priority so no assumption of priority is represented by the table.

Criteria	IHE/SOAP	SMTP	REST	XMPP
Interoperability with NHIN Exchange	Uses same specification as NHIN Exchange	Can operate in parallel with NHIN Exchange, using same HISP user and authentication services, sending direct messages on the secure SMTP backbone.	Not needed in most cases, step-up/step-down in small set of cases	XMPP can co-exist with NHIN Exchange as a parallel capability. To interoperate between the two there would a XMPP-SOAP binding that would be used to exchange content.
Ease of provider interaction	Supports automated metadata-based workflow management	Scales easily upward from simple messages to full XDM support, allowing for very simple message workflow, or sophisticated content-driven XDM-encoded workflow for those environments that can handle it.	Depends on level of metadata provided by sender	Can be incorporated into existing Provider interfaces with minimal effort. New Interfaces can also be developed easily if desired.
Ease of technology integration	Already implemented by many EHRs (see [1] which contains results for US as well as Europe.	Already implemented by some EHRs, very easily added to non-EHR settings (using any standard mail clients.) Many web-based SMTP-backed mail systems to serve as examples for those who want to use a web-based UI.	Addition of REST enabling code needed.	Integrating XMPP with existing technology stacks can be easily accomplished using the open source libraries that are available.
Technology stack needed	SOAP 1.2 + MTOM + ebXML	SMTP + POP3/IMAP4 + RFC 5822 + S/MIME (required for HISP only)	HTTP + RFC 5822 + S/MIME (required for HISP only)	XMPP + S/MIME.
Existing use of Core Protocol- general	Extensive use of SOAP/XML technology in wide set of applications.	Extensive use for email exchange.	HTTP is broadly used; REST is dominant web 2.0 API approach.	Deployed for instant messaging, social networking like Google Wave, Facebook and many real time communication applications.
Existing use – healthcare data sharing	Demonstrated at tradeshows, several production deployments, many in progress deployments, see Where in the World is XDS	Secure email in use in numerous healthcare settings (e.g. Halamka and BIDMC, SES, etc.) Widely used ad hoc. Some use in dentistry.	Used in multiple vendor healthcare interoperability APIs. Demonstrated at tradeshows.	LucentGlow has used XMPP to integrate healthcare enterprises using Google's XMPP server.
Standards/Profiling organization identified to support formalization	IHE	None needed unless ONC desires for formalization, in which case the work would be simple, since the SMTP standards are well defined and widely deployed. (IETF supports substrate standards)	None (IETF supports substrate standards)	None (IETF supports substrate standards)
Security scalability	Supports the certificate based identity assertions (see Security and Trust workgroup), and easy to add User Assertions with SAML. SAML supports federated identity that scales with policy to support many types of authentication.	SMTP+POP3/IMAP user authentication, S/MIME for HISP-HISP, automatically applied by "agent" code. Leverages DNS for PKI management, certificate revocation, etc.	HTTP Authentication + S/MIME HISP-HISP	Security is accomplished using mutual TLS between the HISP's. SASL is used to validate user or end point identities and the relevant certificates.
Privacy Support	IHE BPPC profile confidentiality Code Segmentation SAML assertions with XACML access control capabilities can be added on top of the existing infrastructure.	Direct push model explicitly puts the burden on the sender to be sure that PHI is exposed under HIPAA TP&O, as was explicitly requested by ONC mandate. Highly flexible and well-understood as it maps to existing models of consent and privacy management.	Category is too vague to provide a reasonable answer	XMPP integrates with LDAP directory and any kind of Groups/Roles can be setup and the end user interface customized based on the group/role information.
Content Package Manifest Metadata	Formal and Extensive	Defined in Content Container Specification, use of MIME with optional XDM. Scales readily from simple messages (text only) all the way to full XDM.	Uses the NHIN Direct Content Container Specification (which has gained consensus status and has been thoroughly debated). Use of MIME with optional XDM. Simple yet formalized IETF RFC standards used.	Uses the NHIN Direct Content Container Specification (S/MIME).
Separation of routing information from PHI	For Direct, un-assisted, communications only IP address is exposed. When HISP assist is needed then all or some PHI is exposed to the HISP. Could easily put Health Internet Adddress in SOAP header but step-up/step-down transforms not possible without some PHI exposure	Use of RFC5822 headers for routing information, SMTP package encrypted. Optionally, TLS channel encryption can be used to hide PHI in headers.	Health Internet Address in URI. Use of RFC5822 headers for routing information. Package encrypted.	XMPP uses only the "To" , "From" address for routing purposes. All other information can be packaged within the content or body of the message. The body can be encrypted using TLS + PKI encryption.

Concrete Model Commentary Page