1 / 32

NHIN DIRECT REST IMPLEMENTATION

NHIN DIRECT REST IMPLEMENTATION. June 10, 2010 Face to Face Meeting. Some Definitions. REST – Representational State Transfer Introduced in Roy Fielding’s PhD thesis in 2000 Theory Requests and responses between clients and servers embody the transfer of “representations” of “resources”

mariko-white
Download Presentation

NHIN DIRECT REST IMPLEMENTATION

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Some Definitions • REST – Representational State Transfer • Introduced in Roy Fielding’s 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+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 client’s 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 Source HISP Source SMTP/POP3 HTTP/REST HTTP/REST Backbone Dest HISP Hosted by NHIN Exchange Node NHIN Exchange Node XDR (Doc Submission) • NHIN Exchange node exposes itself as a HISP & NHIN Direct address • NHIN Exchange node is Source and Destination • NHIN Direct addressing works “naturally”

  9. NHIN Exchange Integration Source HISP Source SMTP/POP3 HTTP/REST XDR (Doc Submission) NHIN Exchange Node • 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

  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. Adam’s 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: <eb00ed94-951b-4747-8e86-585b31fe01bf@nhin.BetaClinic.com:> 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. Bob’s REST-enabled EMR system lists Dr. Bob’s 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 <?xml version="1.0" encoding="UTF-8"?> <feed xmlns="http://www.w3.org/2005/Atom"> <title>Messages for DrBob@nhin.BetaClinic.com</title> <link href="https://nhin.hisp-b.com:8443/nhin/v1/nhin.BetaClinic.com/DrBob/messages" /> <id>https://nhin.hisp-b.com:8443/nhin/v1/nhin.BetaClinic.com/DrBob/messages</id> <updated>2010-06-09T13:57:43Z</updated> <entry> <title>message: b5d9857c-2935-4de5-8144-abdb1560049c</title> <link href="https://nhin.hisp-b.com:8443/nhin/v1/nhin.BetaClinic.com/DrBob/messages/ b5d9857c-2935-4de5-8144-abdb1560049c" /> <author> <name>DrAdam@nhin.AlphaClinic.com</name> <email>DrAdam@nhin.AlphaClinic.com</email> </author> <id>https://nhin.hisp-b.com:8443/nhin/v1/nhin.BetaClinic.com/DrBob/messages/ b5d9857c-2935-4de5-8144-abdb1560049c</id> <updated>2010-06-09T13:54:02Z</updated> <content type="html">Re: John Doe Summary Please</content> </entry> </feed>

  18. Demo: Dr Bob retrieves Dr Adam’s message • Dr. Bob’s REST-enabled EMR system retrieves Dr. Adam’s 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 <DrBob@nhin.BetaClinic.com>; Wed, 9 Jun 2010 09:54:02 -0400 (EDT) Message-ID: <A71AABCA65524951B4655BA4455CB897@e6500brepet> From: "Doctor Adam" <DrAdam@nhin.AlphaClinic.com> To: DrBob@nhin.BetaClinic.com References: <30295560.24.1276090825046.JavaMail.NHIN@localhost> In-Reply-To: <30295560.24.1276090825046.JavaMail.NHIN@localhost> 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 IMPLEMENTATIONCare360 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 Message Sender Sending Physician Practice NHIN Direct Recipient Address HIPAA Disclosure Reason

  25. Attaching Clinical Documents w/ Patient Context

  26. Attaching Clinical Documents w/ Patient Context

  27. Message Ready to be Sent Out Structured Clinical Attachments

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

  29. Message Received in Recipient’s Inbox Message Recipient Receiving Physician Practice Referral Message

  30. Recipient Viewing Message Clinical Attachment View

  31. Message Retrieval - HISP Processing Note: Message shown in decrypted form • Retrieval of messages • REST URL (GET) : https://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-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/status 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

More Related