NHIN DIRECT REST IMPLEMENTATION June 10, 2010 Face to Face Meeting

Some Definitions »REST – Representational State Transfer »Introduced in Roy Fieldings PhD thesis in 2000 »Theory Requests and responses between clients and servers embody the transfer of representations of resources –Example: Resource is a List of Messages. Representations could be an XML or HTML expression of the list. Resource: Any addressable concept »Practice HTTP methods (typically GET, POST, PUT, DELETE) applied to resources expressed as URIs HTTP status codes for coarse-grained response interpretation MIME Content-Type header for request and response interpretation

Status of Effort »REST Spec: »Ruby on Rails HISP implementation OpenSSL S/MIME message-based security (sign and encrypt) /certs resource for retrieving X.509 certificates »Java-based HISP implementation (Spring MVC 3.0) REST and SMTP/POP3 edge protocol support –Functioning with standard client & REST test clients –In prototype with MedPlus Care360 EHR as Source/Destination –In prototype with Google App Engine/Google Health as Destination S/MIME message-based security (sign/encrypt). TLS between HISPs /certs resource for retrieving X.509 certificates »Java-based HISP implementation (JAX-RS - Jersey) Full implementation of REST messaging API

The Case for REST »Simple Knowledge of HTTP method primitives, Content-Type, and URL formation rules is all that is required »Ubiquitous HTTP is well understood with client libraries in virtually any environment and servers available for free »Proven HTTP has been the protocol of the web for years »Extensible New URL formation rules and Content-Type headers to address new resources »Scalable REST HTTP-based services scale using well-understood techniques

The Case for REST »Integration Simplicity Low level of knowledge needed (HTTP methods, headers, and URL formation rules) »Tooling Lots of development tools to make coding simple (Spring MVC 3.0, JAX-RS, etc…) »Natural X.509 certificate directory mechanism /certs resource »Available running code A Java HISP and Ruby-on-Rails HISP implementation is available and can be up and running in 30 minutes.

Security & Trust »S/MIME approach implemented successfully OpenSSL (Ruby on Rails) nhin-d-jagent (Java) »HISP-to-HISP TLS Decided this was needed for on-the-wire privacy of To/From headers –What trust anchors (CAs) to allow in TLS clients truststore? Still debating merits of using client certificates in TLS –Implies single trust anchor for TLS Is that a Bad Thing given the multiple anchors allowed in the S/MIME message-based approach? »Convenient distribution of certificates via a REST resource

NHIN Exchange Integration »Axiom #1: The vast majority of push-based communication through NHIN Direct will not need to involve an endpoint implemented using NHIN Exchange protocols. »Axiom #2: The communication that does originate from or target an NHIN Exchange node will involve critical use-cases for the industry. »Approach Design primarily for Axiom #1 and avoid step up/down to NHIN Exchange formats for the vast majority of messages (avoiding unnecessary complexity and potentially allowing more small players into the HISP market) Design for Axiom #2 by characterizing NHIN Exchange nodes as Source or Destination actors. –Example: Implement via an NHIN CONNECT adapter. »Confession: The REST team has not yet had time to prototype this approach.

NHIN Exchange Integration »NHIN Exchange node exposes itself as a HISP & NHIN Direct address NHIN Exchange node is Source and Destination »NHIN Direct addressing works naturally Source Source HISP SMTP/POP3 HTTP/REST Dest HISP Hosted by NHIN Exchange Node Dest HISP Hosted by NHIN Exchange Node NHIN Exchange Node XDR (Doc Submission) HTTP/REST Backbone

NHIN Exchange Integration »NHIN Exchange node does not expose itself as an NHIN Direct address NHIN Exchange node is still Source and Destination »NHIN Direct addressing works less naturally Without an NHIN Direct address, each NHIN Exchange node becomes a custom connection for a HISP Source Source HISP SMTP/POP3 HTTP/REST NHIN Exchange Node XDR (Doc Submission)

Demo: REST Source to Destination & Reply »Dr. Bob (REST EMR) sends a request to Dr. Adam (SMTP ) »Dr. Adam replies to Dr. Bob »Two separate HISPs »S/MIME sign/encrypt/decrypt/verify on HISPs using certs/keys at the individual level (Dr. Bob and Dr. Adam)

Demo: Dr Bob sends request to Dr Adam »Dr. Bob sends a request through his REST-enabled EMR system to Dr. Adam for information about Dr. Adams recent visit with patient John Doe. »REST URL (POST): » »Content is an RFC 5322 formatted message with one part (next slide) The EMR is responsible for formatting the message for transport

Demo: RFC 5322 Message from Dr. Bob From: To: Date: Fri, 04 Jun :20: Subject: John Doe Summary Please Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=" " This text is traditionally ignored but can help non-MIME compliant readers provide information Content-Type: text/plain Hi Adam. Will you please send me your summary on John Doe who lives at at 123 Main Street, Eagan, MN. I'm seeing him at 2:00pm today, and any info from your visit with him last Friday would be helpful. Bob

Demo: Dr Adam receives message in client

Demo: Dr Adam client configuration

Demo: Dr Adam replies with PDF attachment

Demo: Dr Bob lists his incoming messages »Dr. Bobs REST-enabled EMR system lists Dr. Bobs incoming messages. »REST URL (GET): » »Content is an Atom feed (next slide) EMR formats the list for presentation to Dr Bob

Demo: Message List content for Dr. Bob Messages for T13:57:43Z message: b5d9857c de abdb c <link href=" b5d9857c de abdb c" /> b5d9857c de abdb c T13:54:02Z Re: John Doe Summary Please

Demo: Dr Bob retrieves Dr Adams message »Dr. Bobs REST-enabled EMR system retrieves Dr. Adams incoming message by dereferencing the URL given in the message list feed »REST URL (GET): » »Content is an RFC message (next slide) EMR formats the message for presentation to Dr Bob

Demo: RFC 5322 Message from Dr. Adam (part 1) Received: from Minnesota.hfc.comcastbusiness.net ([ ]) by ip (JAMES SMTP Server 2.3.2) with SMTP ID 79 for ; Wed, 9 Jun :54: (EDT) Message-ID: From: "Doctor Adam" To: References: In-Reply-To: Subject: Re: John Doe Summary Please Date: Wed, 9 Jun :53: MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail X-MimeOLE: Produced By Microsoft MimeOLE V X-EsetScannerBuild: 7267 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001D_01CB07B1.4CF56EB0 This is a multi-part message in MIME format.

Demo: RFC 5322 Message from Dr. Adam (part 2) =_NextPart_000_001D_01CB07B1.4CF56EB0 Content-Type: text/plain; format=flowed; charset="iso ; reply-type=original Content-Transfer-Encoding: 7bit Bob: Attached is the summary of John Doe's visit. Thanks for seeing him on such short notice. Adam =_NextPart_000_001D_01CB07B1.4CF56EB0 Content-Type: application/pdf; name="JohnDoeSummary.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="JohnDoeSummary.pdf" JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nLVYWW8URxB+318xUl5mIrbp++ANAkpABEFYkQfIg/FJsNewXkv436d6pruq =_NextPart_000_001D_01CB07B1.4CF56EB0--

NHIN DIRECT REST IMPLEMENTATION Care360 EHR Demo

Demo: EHR Integration with REST based HISP »Objective: Demonstrate NHIN Direct Provider to Provider messaging within Care360 EHR utilizing REST based HISP services Support creation and submission of outbound NHIN Direct messages Support retrieval and consumption of inbound NHIN Direct Messages »Dr. Wynne sends a patient referral to specialist Dr. Galgali at another practice »Dr. Galgali receives the referral and adds the content to the patient chart »Single HISP servicing nhin.Care360.com domain »S/MIME sign/encrypt/decrypt/verify on HISPs using certs/keys at the individual level (Dr. Wynne and Dr. Galgali)

Provider – Specialist Referral Flow

Basic NHIN Direct Message Creation HIPAA Disclosure Reason NHIN Direct Recipient Address Message Sender Sending Physician Practice

Attaching Clinical Documents w/ Patient Context

Message Ready to be Sent Out Structured Clinical Attachments

Message Submission - HISP Processing »Submission of RFC 5322 formatted message over one- way TLS with basic auth REST URL (POST): om/galgali/messages »Security and trust java agent used for S/MIME processing and trust verification »Message stored in repository for retrieval Note: Message shown in decrypted form

Message Received in Recipients Inbox Receiving Physician Practice Message Recipient Referral Message

Recipient Viewing Message Clinical Attachment View

Message Retrieval - HISP Processing »Retrieval of messages REST URL (GET) : Content is Atom feed (see below) »Retrieval of specific message REST URL (GET): 46df-a9d7-29a078f11907https://nhin.care360.com:8443/nhin/v1/nhin.care360.com/galgali/messages/42f c- 46df-a9d7-29a078f11907 »Client acknowledgement of retrieved message REST URL (PUT): 46df-a9d7-29a078f11907/statushttps://nhin.care360.com:8443/nhin/v1/nhin.care360.com/galgali/messages/42f c- 46df-a9d7-29a078f11907/status Note: Message shown in decrypted form Available messages in Atom format

Implementation Highlights »1 week, 1 engineer to implement the Care360 EHR/HISP connectivity using REST as the integration approach »Standards-based HTTPS RFC 5322 format »Standard library support JavaMail API Apache Commons »Also prototyped NHIN Direct message exchange between Care360 EHR and SMTP client using REST implementation SMTP gateway