Upload
ramona
View
27
Download
0
Tags:
Embed Size (px)
DESCRIPTION
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” - PowerPoint PPT Presentation
Citation preview
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: [email protected]
Date: Fri, 04 Jun 2010 08:20:17 -0400
Subject: John Doe Summary Please
Message-ID: <[email protected]:>
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 [email protected]</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>[email protected]</name>
<email>[email protected]</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 <[email protected]>;
Wed, 9 Jun 2010 09:54:02 -0400 (EDT)
Message-ID: <A71AABCA65524951B4655BA4455CB897@e6500brepet>
From: "Doctor Adam" <[email protected]>
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