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”– 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: 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

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

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”

SourceSource Source HISPSource HISPSMTP/POP3HTTP/REST

Dest HISPHosted by NHIN Exchange Node

Dest HISPHosted by NHIN Exchange Node

NHIN Exchange

Node

NHIN Exchange

Node XDR(Doc Submission)

HTTP/RESTBackbone

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

SourceSource Source HISPSource HISPSMTP/POP3HTTP/REST

NHIN Exchange

Node

NHIN Exchange

Node

XDR(Doc Submission)

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)

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

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

Demo: Dr Adam receives message in e-mail client

Demo: Dr Adam e-mail client configuration

Demo: Dr Adam replies with PDF attachment

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

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>

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

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.

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

NHIN DIRECT REST IMPLEMENTATIONCare360 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 ReasonHIPAA Disclosure Reason

NHIN Direct Recipient AddressNHIN Direct Recipient Address

Message SenderMessage Sender Sending Physician PracticeSending Physician Practice

Attaching Clinical Documents w/ Patient Context

Attaching Clinical Documents w/ Patient Context

Message Ready to be Sent Out

Structured Clinical Attachments

Structured Clinical Attachments

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.com/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 Recipient’s Inbox

Receiving Physician PracticeReceiving Physician PracticeMessage RecipientMessage Recipient

Referral MessageReferral Message

Recipient Viewing Message

Clinical Attachment ViewClinical Attachment View

Message Retrieval - HISP Processing

» 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

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