This worksheet outlines the capabilities of the proposed XMPP Concrete Implementation of the NHIN Direct specifications. The structure below follows the Implementation Capability Worksheet created by the Concrete Implementation Workgroup.

1. Overview

1.1 Provide a high-level end-to-end description of your implementation:

The XMPP implementation is based on the XMPP (Extensible Message and Presence Protocol) protocol which is widely used in real-time communication with XML as the base format for exchanging information. Some of the common applications of XMPP include social networking applications Facebook and Google wave, Multi-media conferencing applications, Instant Messaging applications, Group chat applications, and Geolocation applications.
 
  A high-level end-to-end view of the XMPP based implementation which consists of clients and servers are shown in the Figure below:
 
 
 
 
  The term client is mapped to the Source and Destination constructs in the abstract model, and the term server is mapped to the HISP in the abstract model. The communication between clients and servers are performed using the XMPP protocol and its extensions. The communication between servers (HISP to HISP) is also performed using the XMPP protocol and its extensions. The details of the communication are documented on the XMPP Implementation Specification page.
 
 
  The current NHIN Direct XMPP Implementation includes a Java "XMPP client" application, and a Java "XMPP server" application. The client and the server applications are using open source COTS products and libraries which are widely available in the open source XMPP community. The clients can be implemented using various languages such as perl, php, c, c#, .NET, flash, python, ruby, java script. The client applications can be created such that they only use a simple web browser. For a detailed list of available COTS libraries and products visit the link at XMPP Foundation.

1.2 Provide Software block diagram for representative end-to-end system implementation:

The various COTS and custom components that are required for a representative XMPP instantiation are shown in the diagram below. All COTS components are open source technologies that are easily available or already part of the internet infrastructure like DNS. The custom components are developed specifically for NHIN Direct to handle content container specification, security specification and user interface functions.
 
 
 
  An example instantiation of the above products and architecture is shown in the diagram below. In this instantiation both the Source and Destination are shown to be part of the same HISP for simplicity.
  The Server application is made up of OpenFire XMPP server which provides the XMPP services to all registered clients (source or destination). The OpenFire XMPP server is integrated with OpenLDAP Directory which provides account management functionality. The OpenLDAP stores all source and destination accounts along with their passwords that would be used for authentication. The OpenFire XMPP server is further integrated with MySQL database to store transaction logs, offline messages as specified by the configuration.
  The Client application is built in Java and provides simple user interface for end users to send and receive messages, manage buddy lists. The application is built using the Smack XMPP client library which provides the XMPP functionality along with Eclipse and JDK libraries for User Interface, and MIME functionality.

1.3 Describe the current overall state of the implementation:

The current XMPP implementation has a Client application that is custom developed along with it's user interfaces. The Server application is instantiated currently using COTS products and the NHIN Exchange Plugin has not been developed as of yet. This will depend on the security group and IHE group's outcome.
 
  On going work includes the following: Signing and Encrypting of messages from clients to servers, develop the NHIN Exchange Plugin and baseline the software for public consumption.

1.4 Describe the working group participants and contributions:

Name	Affiliation
Nagesh Bashyam	Harris Corporation
Will Ross	Redwood MedNet
Richard Braman	EHR Doctors, Inc.
Wesley Combs	CareSpark/Lucent Glow

2. Benefits/Drawbacks

2.1 Outline why you believe this is the best approach to achieving the goals of NHIN Direct.

The goal of NHIN Direct is to provide standards and services which allow organizations to deliver simple, direct, secure and scalable transport of health information over the Internet between known participants in support of Stage 1 meaningful use.
 
  The XMPP based implementation operates at it's sweet spot for the above goals since the protocol is designed for "Simple", "Direct" message pushes between 2 end points. The social networking phenomena is a result of this "Simple", "Direct" message exchange pattern.
 
  The following is a list of benefits that the XMPP protocol provides for NHIN Direct:
 
  Technology outreach:

Proven Technology: Widely deployed across the internet for instant messaging and real time communication.
Good Development Support: Many open source versions of XMPP libraries and servers exist which can be adopted by the development community for their respective platforms and enhanced as required.
Flexible: The protocol is specified with dozens of standard extensions which facilitate adding services or enhancing the core capabilities very easily.

Functional Benefits: (Features required to meet NHIN Direct specifications and services)

Asynchronous push-based messaging.
Secure channel encryption with TLS
Secure Authentication and authorization framework using SASL.
Support for certificate based authorization and authentication using SASL.
Single HOP Server Federation where 2 servers can communicate directly with each other and do not have to go through an intermediary.
Large File Transfer capability: Since the XMPP servers allow file transfer as an extension, as the size of the files get large the protocol can directly transfer files between end points without any size limitation problems that an "In-band" transfer would encounter.
Contact Lists (Buddy Lists) that an end point can create to communicate with commonly known end points. This is very powerful especially when the end point is a real user who can decide to have a Buddy List with groups of "Specilists", "Labs", "Pharmacies" etc, with whom the user wants to exchange health information.

The following are additional benefits of the XMPP protocol beyond the minimum required for supporting NHIN Direct. These features can be exploited by the HISP to provide value added services to the end users and drive innovation.

1. Presence:

- XMPP protocol allows end points to detect the presence of other end points (i.e is the source/destination available, not available right now ?) which is very useful when end points want to have live conversations in real-time. When Presence is coupled with real end users there can be instantaneous live conversations and co-ordination between providers on treating a particular patient or condition.

2. Service Discovery:

- XMPP protocol provides capability to discover services offered by other XMPP servers in real-time, thus enabling end points to discover new services as they become available. This feature increases the flexibility of the overall approach, where by if new use cases in health IT require new services or capabilities they can be added and extended without impacting the existing infrastructure. As HISP's roll out the new services their end points can make use of them transparently. This will be crucial as Meaningful Use evolves over time and new services will be needed to meet the criteria that will be outlined.

3. Multi-media capabilities

- XMPP offers multi-media collaboration capabilities like Multi-User chat, Voice over IP (VOIP) communications which can be very useful to collaborate "live" between providers in treating a patient.

4. Cloud Computing:

- XMPP is being considered now to manage cloud infrastructure via structure XML messages since the protocol is a light weight messaging protocol, agnostic to payload and is based on XML. This could be very useful as NHIN Direct implementation is adopted and scaling of HISP services is considered a critical need for the community.

5. Publish-Subscribe capabilities:

- XMPP protocol offers a "publish/subscribe" capability beyond the asynchronous push messaging. This feature will be valuable as NHIN Direct moves towards public health monitoring and organizations want to monitor certain type of events across the nation for detecting outbreaks, bio-terrorism activities etc.

2.2 Outline any drawbacks to this approach

Some of the drawbacks of this approach would be the following:

- The implementation requires additional custom developed software which is added effort unless a reference implementation can be created for use by all organizations adopting NHIN Direct implementations.
- The implementation requires additional custom developed software to interact with the current NHIN Exchange.

3. Specific Artifacts

3.1 Describe the status of working code

The current XMPP implementation has a Client application that is custom developed along with it's user interfaces. The Server application is instantiated currently using COTS products and the NHIN Exchange Plugin has not been developed as of yet. This will depend on the security group and IHE group's outcome.
 
  On going work includes the following: Signing and Encrypting of messages from clients to servers, develop the NHIN Exchange Plugin and baseline the software for public consumption.

3.2 Describe the status of written specifications

The XMPP Implementation Specification page describes the NHIN Direct XMPP based implemetation. The core XMPP protocol specifications and the XMPP extension protocols (XEP's) are documented at [1].

3.3 Describe the status of test tools and cases

The current XMPP based implementation is being updated with unit tests. Along with the unit tests, the client application which is part of the XMPP based implementation provides a quick and easy way of testing the functionality of the software from a user story perspective.

3.4 Describe the production readiness of the working code e.g., are errors and edge cases handled, are administrative and monitoring tools available, etc.

The software being developed is currently in a "proof of concept" state. The XMPP COTS products and libraries come with extensive configuration, adminstrative and monitoring tools for administrators to manage the XMPP Servers (HISP's) and their clients.

4. Abstract Model

4.1 Describe how each numbered transaction is supported by the implementation

The XMPP Implementation Specification page describes how the Abstract Model transactions are mapped to the XMPP based implementation.

4.2 Describe how each defined "term" in the abstract model is instantiated in the implementation

The XMPP Implementation Specification page describes how the Abstract Model terms are mapped to the XMPP based implementation.

5. User Stories

5.1 Describe how each user story is supported by the implementation. ALL stories regardless of priority should be addressed; working code may be focused on the priority 1 items.

All NHIN Direct user stories require a message routing mechanism from a source to a destination through a HISP. Along with the routing mechanism the Content Container specification and the Security model support all user stories. The current XMPP based implementation supports all user stories and uses the same common mechanisms outlined by the Addressing, Content Specification, and Security work groups.

6. Security and Trust

6.1 Describe how each consensus requirement is supported by the implementation.

The Security and Trust workgroup has not reached consensus but the following are the security aspects that have been implemented in the XMPP based implementation to support the draft security proposal.
 
  1. The client to server communication (Source/Destination to HISP) is encrypted using TLS.
  2. The clients are authenticated to the server using SASL mechanisms. (SASL PLAIN allows user + pwd, SASL EXTERNAL allows X509 certificates).
  3. The Server to Server communication will be encrypted using TLS.
  4. The Server to Server authentication will be performed using SASL EXTERNAL mechanism which supports X509 certificates.
 
  In addition to the above the XMPP implementation is testing signing and encrypting payload using PKI infrastructure. The security aspects described above are shown in the diagram below.
 
 
 
  In addition the following additional capabilities of the XMPP server provide added security.

- Server white-listing capability (The capability provides an easy mechanism for HISP's to determine the other HISP's that they would like to communicate with). This feature may or may not be used in the real world but allows organizations to block organizations or spams.
- Endpoint/User level blocking: All end points or users have the capability to maintain rosters (buddy lists) of other endpoints/users that they wish to communicate with. A basic agreement to communicate is established initially upon mutual consent for communication.

7. Comprehensive HIE

7.1 Describe the mechanisms by which the implementation can interact with NHIN Exchange implementations.

The NHIN Exchange uses SOAP over HTTP for it's transactions. For XMPP to communicate with SOAP the XMPP extension protocol XEP-072 can be used. This plug-in software that invokves the SOAP server has to be written and added to the XMPP server. The plug-in is similar to a "bot" that can act upon certain key information and act as a gateway to the SOAP endpoints. In addition to the SOAP binding, a simple NHIN Exchange plugin can be created and added to the XMPP server to intercept the packets for NHIN Exchange end points and route them appropriately using SOAP/HTTP.

8. Other Workgroups

8.1 If the implementation deviates from requirements of the Addressing, Content Packaging or Individual Involvement workgroups, describe and explain the reasons here.

The XMPP based implementation adheres to the specifications and outputs produced by the Addressing, Content Packaging and Individual Involvement workgroups.

9. Cost and complexity of development

9.1 Describe what new code is required to create a complete implementation vs what can be used off-the-shelf.

A large portion of the required XMPP implementation is available via COTS products and libraries. The new code that is required to be written is shown in section 1.2. Most of the software created is on the client application.

9.2 Describe library and required component availability across platforms and frameworks.

The XMPP protocol has a wide range of open source products to choose from for the various platforms. The open source products for XMPP servers are listed at [2] and the open source libraries that exist to support client application development are listed at [3]

9.3 How does this approach integrate with existing mainstream healthcare applications ? Describe cost/complexity of integration.

The existing healthcare systems can interface with an XMPP based implementation in multiple ways:
  1. Use HTTP to interact with XMPP. (This is an easy mechanism for existing web applications to send/receive data using XMPP protocol).
  2. Use SMTP protocol to interact with XMPP. (An SMTP based existing system can send a Mime Message to the XMPP Client library which can then route the message to the appropriate end point using XMPP protocol).
  3. Use HL7 Messages. (XMPP can provide a common API to send HL7 messages to/from NHIN Direct end points and the existing EHR/EMR systems can use the HL7 messages to interact with XMPP based implementations)
 
  Although NHIN Direct can be implemented using SMTP or HTTP (REST/SOAP), XMPP provides additional benefits as outlined in section 2.1 and hence choosing XMPP can provide a robust innovation platform for health IT. This innovation coupled with the right business model and policies can capture the imagination of the healthcare industry and drive wide-spread electronic health record adoption.
 
  A real world example where health care organizations are using XMPP to integrate existing systems is shown in the diagram below. This real world example is based of the instantiation by LucentGlow Inc to connect existing EHR/EMR systems.

10. Workflow / User Experience

10.1 Describe how a small (1-5 provider) practice with limited IT capability might deploy and service the implementation

I am assuming that small provider practice does not have the capability to implement a HISP function but has internet access capabilities. In this case the following steps would enable the provider to start exchanging electronic health records using the XMPP based implementation.
 
  1. Identify a HISP that provides the right service for the provider and has the right business and security policies.
  2. Subscribe to the HISP service.
  3. Use the HISP provided application to authenticate and access the client application.
  4. Add end points that the provider wishes to communicate with as a "Buddy" or "Contact".
  5. Exchange messages with the other provider or endpoints as desired.

10.2 Describe how a medium practice with an outpatient EMR might deploy and service the implementation.

I am assuming that an EMR might not be able to host and maintain a HISP like service with it's IT staff. So I am assuming that the EMR would contract with a HISP for NHIN Direct Services. The following steps would be followed by the EMR to achieve meaningful electronic health information exchange
 
  1. Identify a HISP that provides the right service for the provider and has the right business and security policies.
  2. Subscribe to the HISP service.
  3. Use the HISP provided application to authenticate and access the client application.
  4. Add end points that the provider wishes to communicate with as a "Buddy"
  5. Exchange messages with the other provider or endpoints as desired.

10.3 Describe how a large practice/hospital might deploy and service the implementation

A large practice or a hospital will typically implement Source, Destination and the HISP actors from the NHIN Direct Abstract Model. The large practice would host the XMPP server within it's IT data center or IT infrastructure facility and would provide the client applications to all the departments within the hospital and potentially even end users within the hospital. This enables a near real-time communication network within the hospital and can even leverage the XMPP framework to enable chat / conference services.
  For integration with existing systems like EHR's/EMR's the hospital would choose one of the above simple integration options outlined in section 9.3 to transfer messages between end points.

10.4 Describe how a patient might participate in the implementation

The HISP within the XMPP implementation can provide PHR types of services to patients and the patients can become end points on the network that are capable of receiving and sending messages to other systems/providers. An alternative approach would be for a PHR vendor to provide REST service end points to patients and the XMPP implementation can be used to "POST" to the user's record.

10.5 Describe how a service provider might create and operate an implementation.

A service provider in the XMPP based implementation can play the role of a HISP. The service provider can differentiate from others by adding value added services to the XMPP based implementation very easily. The service provider would instantiate the XMPP server and would typically provide the following types of services

User Identification, verification and Authorization
Management of Data transfers to NHIN Direct end points (representing the source or destination)
Notify end users of additional value added services like chat, multi-user chat, VOIP applications etc.
Provide discovery services like provider discovery, end point discovery etc.

11. Miscellaneous

11.1 Metadata Handling

11.1.1 Describe what metadata is inherently handled by the implementation

The XMPP based implementation using XML as a base format for all messages. The NHIN Direct messages are created as MIME objects following the Content Packing specification. The protocol requires only the minimum (To, From, Date etc) to route the messages between end points and is agnostic to the rest of the payload.

11.1.2 Explain how more complex metadata could be added to the implementation if it is desired

More complex meta data can be added to the payload as required by the Content Packaging specification and is not required by the XMPP protocol. In order to support interoperability (for example between NHIN Direct and NHIN exchange) if additional metadata is required, it can be easily added to the XMPP based implementation since the base format is flexible XML.

11.2 Content Handling

11.2.1 Describe how the implementation deals with unstructured text content

The XMPP based implementation is payload agnostic and follows the Content Packaging Specification using MIME objects. The content-type of the MIME objects specify the type of content that is being sent in the payload. So unstructured text is part of the payload and the XMPP protocol delivers the payload faithfully to the desired end point.

11.2.2 Describe how the implementation deals with unstructured binary content (e.g. PDF)

The XMPP based implementation is payload agnostic and follows the Content Packaging Specification using MIME objects. The content-type of the MIME objects specify the type of content that is being sent in the payload. So binary conent is part of the payload and the XMPP protocol delivers the payload faithfully to the desired end point.

11.2.3 Describe how the implementation deals with structured content such as CCX.

The XMPP based implementation is payload agnostic and follows the Content Packaging Specification using MIME objects. The content-type of the MIME objects specify the type of content that is being sent in the payload. So any CCX (CCD or C32) document is part of the payload and the XMPP protocol delivers the payload faithfully to the desired end point.

11.3 Extensibility / Future-proofing

11.3.1 How would this implementation approach extensibility in general to support new use cases ?

The XMPP protocol is designed with extensions and there are dozens of extensions already approved and written for many of today's internet information exchange like VOIP, Multi-media, Video conferencing, Multi-user chat etc.
 
  To support future use cases, the right XMPP extension or the core protocol feature that is applicable can be used very easily and adapt existing implementations seamlessly across the transition using "Feature negotiation" capabilities. The feature negotiation capabilities allow XMPP servers to discover features that servers offer and whether they are compatible with each other's features or not.

12. Additional Capabilities

12.1 Describe any other relevant capabilities or use cases facilitated by this implementation.

The XMPP protocol is a light weight protocol for point to point messaging and can be used in a variety of ways in the future. The capabilities of XMPP will allow any NHIN Direct end points to push relevant medical information to the provider when they need the information at the point of care in a secure manner. Some of the capabilities of XMPP which can be exploited to innovate the next generation health care applications are:

Presence detection for effective monitoring of the end points, systems, availability etc.
Service discovery to add new services without
Large File Transfer capability for out of band delivery
Flexible Security Model with TLS + SASL to add custom authentication mechanisms.
Session management capabilities that allow multi-media streaming, VOIP etc.
Spam protection by using buddy lists and rosters
White listing of domains that allows blocking of servers/domains that are not allowed to communicate.
Publish-subscribe capability to allow organizations to monitor certain health based events across the country.

XMPP Implementation Capability Worksheet