Concrete Model Comparison
Jump to navigation
Jump to search
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.
Concrete Model Commentary Page
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 |
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 |
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