An XMPP (Extensible Message and Presence Protocol) based implementation for NHIN Direct 1

Agenda »Overview NHIN Direct and XMPP Why XMPP ? »Mapping of the Abstract Model to XMPP implementation »Security Model of the XMPP implementation »XMPP implementation of the Content Container »HIE Interoperability using XMPP »Q & A / Demo

Overview 3 »NHIN Direct project will develop standards and services, which will 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. »XMPP protocol provides capabilities that allows realization of the NHIN Direct. Simple – Built on Internet and DNS, Many open source libraries to implement applications, user interfaces and integrate with existing systems and workflows. Direct – Realized using asynchronous message delivery, along with a publish-subscribe mechanism for specific events. Secure – Realized using TLS channel encryption, SASL authentication and authorization mechanisms, and extensive support for X509 based PKI infrastructure. Scalable – Realized using direct “Server Federation”, Clustering features of XMPP servers, A single XMPP server can support 1000’s of end points.

Overview Cont’d – Why XMPP 4 »As explained in the previous slide the XMPP protocol supports all the basic capabilities required to meet NHIN Direct goals. »In addition, XMPP can serve as the “Innovation Platform” providing capabilities for HISP’s to innovate and create the next generation healthcare applications using: Presence features Direct Server to Server federation, no intermediaries thus reducing the probability of attack on the internet. Out of band File Transfer features Service Discovery and negotiation features Publish-Subscribe services Collaboration services Protocol binding support for HTTP/S, SOAP etc. Real time communication features.

Abstract Model Mapping to XMPP Implementation 5 »NHIN Direct Backbone Protocol XMPP over TLS. »NHIN Direct HISP Address Directory The servers, and end points are discovered using DNS directories and DNS SRV lookups.

Abstract Model Mapping to XMPP Implementation Cont’d 6 »NHIN Direct Address XMPP uses addresses which are similar to addresses Addresses come in two formats called the short address and the full address. –The short address is of the format –The full address is of the format For most practical applications the short address is sufficient. »NHIN Direct Message Mime Message carrying different payloads like xml data, documents and binary data wrapped in XMPP xml tags. The Mime Message can be signed and encrypted using PKI infrastructure. »NHIN Direct Source/Destination Edge Protocol XMPP provides flexible options for deployment and can interface with various protocols based on the deployment architecture. The following are the most widely used options for deployment. –XMPP with TLS. (Using standard XMPP ports). –XMPP over HTTP (HTTPS).

Security Model of the XMPP Implementation 7 Channel Security: »The client to server communication (Source/Destination to HISP) is encrypted using TLS based on X509 server certificates. »The clients are authenticated to the server using SASL mechanisms. SASL PLAIN uses (user + pwd) SASL External supports client certificates. »The Server to Server communication will be encrypted using TLS. »The Server to Server authentication/authorization is performed using SASL External mechanism. (X509 certificates)

Security Model of the XMPP Implementation Cont’d 8 Certificate Support: »Client Certificates are distinct from server certificates Client certificates can be at the individual level or at the organization level »Server Certificates are distinct from client certificates »Allows certificate chains and/or anchors for certificate validation. »Allows certificate revocation using OSCP and/or locally cached CRL’s. »Payload Signing and Encryption will be accomplished using NHIN-D JAgent.

Content Container Implementation 9 Content Package Metadata »XMPP uses “To”, and “From” to route the message from source to destination. »Header information as it is currently specified is sufficient for routing between HISP’s. Payload: »All attributes that are not part of the Header information are being packaged as part of the payload. »Once the Content Manifest is finalized and agreed upon, the XMPP implementation can be enhanced to support the required additional data. Note: This could inhibit adoption if the data is required to be entered manually vs being extracted from other payload information.

HIE Interoperability 10

HIE Interoperability Cont’d 11 Scenario4: Interacting with existing EHR/EMR systems

Prototype Instantiation and Configuration 12

Current Status of Prototype 13 »Establish XMPP servers in the cloud »Basic Client / Server and Server to Server Messaging Infrastructure in place. »Secure TLS Channels established between client and Servers, and Server to Servers Certificates from StartSSL were created and used with the prototype. »Directory Integration for user account management with LDAP »Simple User Interface to interact with the XMPP implementation and for account provisioning. »Ongoing Activities: (Not completed) Signing and Encrypting the MIME Message. Proof of concept for Interoperability between NHIN Exchange and NHIN Direct. Creating production level architecture and design documents.

Q & A 14