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

2. 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

3. Status of Effort »REST Spec: http://nhindirect.org/REST+Implementationhttp://nhindirect.org/REST+Implementation »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 email 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

4. 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

5. 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.

6. 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 https://nhin.DodgeClinic.com/nhin/v1/nhin.DodgeClinic.com/DrJohnson/certs

7. 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.

8. 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

9. 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)

10. Demo: REST Source to E-mail Destination & Reply »Dr. Bob (REST EMR) sends a request to Dr. Adam (SMTP e-mail) »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)

11. 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): »http://nhin.hisp-b.com/nhin/v1/nhin.AlphaClinic.com/DrAdam/messages »Content is an RFC 5322 formatted message with one part (next slide) The EMR is responsible for formatting the message for transport

12. Demo: RFC 5322 Message from Dr. Bob From: DrBob@nhin.BetaClinic.com To: DrAdam@nhin.AlphaClinic.com Date: Fri, 04 Jun 2010 08:20:17 -0400 Subject: John Doe Summary Please Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8837833223134.12.9837473322" This text is traditionally ignored but can help non-MIME compliant readers provide information. --8837833223134.12.9837473322 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 --8837833223134.12.9837473322--

13. Demo: Dr Adam receives message in e-mail client

14. Demo: Dr Adam e-mail client configuration

15. Demo: Dr Adam replies with PDF attachment

16. Demo: Dr Bob lists his incoming messages »Dr. Bobs REST-enabled EMR system lists Dr. Bobs incoming messages. »REST URL (GET): »http://nhin.hisp-b.com/nhin/v1/nhin.BetaClinic.com/DrBob/messages »Content is an Atom feed (next slide) EMR formats the list for presentation to Dr Bob

17. Demo: Message List content for Dr. Bob Messages for DrBob@nhin.BetaClinic.com https://nhin.hisp-b.com:8443/nhin/v1/nhin.BetaClinic.com/DrBob/messages 2010-06-09T13:57:43Z message: b5d9857c-2935-4de5-8144-abdb1560049c <link href="https://nhin.hisp-b.com:8443/nhin/v1/nhin.BetaClinic.com/DrBob/messages/ b5d9857c-2935-4de5-8144-abdb1560049c" /> DrAdam@nhin.AlphaClinic.com https://nhin.hisp-b.com:8443/nhin/v1/nhin.BetaClinic.com/DrBob/messages/ b5d9857c-2935-4de5-8144-abdb1560049c 2010-06-09T13:54:02Z Re: John Doe Summary Please

18. 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): »https://nhin.hisp-b.com:8443/nhin/v1/nhin.BetaClinic.com/DrBob/messages/b5d9857c-2935-4de5-8144-abdb1560049c »Content is an RFC 5322 email message (next slide) EMR formats the message for presentation to Dr Bob

19. Demo: RFC 5322 Message from Dr. Adam (part 1) Received: from 173-11-39-65-Minnesota.hfc.comcastbusiness.net ([173.11.39.65]) by ip-10-251-215-181 (JAMES SMTP Server 2.3.2) with SMTP ID 79 for ; Wed, 9 Jun 2010 09:54:02 -0400 (EDT) Message-ID: From: "Doctor Adam" To: DrBob@nhin.BetaClinic.com References: In-Reply-To: Subject: Re: John Doe Summary Please Date: Wed, 9 Jun 2010 08:53:59 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-EsetScannerBuild: 7267 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001D_01CB07B1.4CF56EB0 This is a multi-part message in MIME format.

20. Demo: RFC 5322 Message from Dr. Adam (part 2) ------=_NextPart_000_001D_01CB07B1.4CF56EB0 Content-Type: text/plain; format=flowed; charset="iso-8859-1; 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--

21. NHIN DIRECT REST IMPLEMENTATION Care360 EHR Demo

22. 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)

23. Provider – Specialist Referral Flow

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

25. Attaching Clinical Documents w/ Patient Context

27. Message Ready to be Sent Out Structured Clinical Attachments

28. Message Submission - HISP Processing »Submission of RFC 5322 formatted message over one- way TLS with basic auth REST URL (POST): https://nhin.care360.com/nhin/v1/nhin.care360.c 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

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

30. Recipient Viewing Message Clinical Attachment View

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

32. 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