Meeting Etiquette Please announce your name each time prior to making comments or suggestions during the call Remember: If you are not speaking keep your.

Meeting Etiquette

• Please announce your name each time prior to making comments or suggestions during the call

• Remember: If you are not speaking keep your phone on mute• Do not put your phone on hold – if you need to take a call, hang up

and dial in again when finished with your other call – Hold = Elevator Music = very frustrated speakers and participants

• This meeting, like all of our meetings, is being recorded– Another reason to keep your phone on mute when not speaking!

• Feel free to use the “Chat” or “Q&A” feature for questions or comments

NOTE: This meeting is being recorded and will be posted on the Wiki page after the meeting

From S&I Framework to Participants:Hi everyone: remember to keep your phone on mute

1

© 2011 The MITRE Corporation. All rights Reserved.

OverviewWebEx

June 28, 2012, 11 am – 12 pm EDT

Powering Secure, Web-Based Health Data Exchange

Approved for Public Release: 12-2797. Distribution Unlimited. © 2012 The MITRE Corporation. All Rights Reserved.


3

Overview

■ What is RHEx?■ Why pursue a RESTful exchange?■ Philosophy■ RHEx Implementation■ NwHIN Harmonization■ Ways to Participate


4

What is ?

■ An open source, exploratory project to apply proven web technologies to demonstrate a simple, secure, and standards-based health information exchange– Sponsored by the Federal Health Architecture (FHA) program– Called RESTful Health Exchange (RHEx)– Intended to inform a path forward on a RESTful health

exchange

■ A Fiscal Year 2012 project being demonstrated in 2 phases– Phase I: Security approach for a RESTful health information

exchange (April-July 2012)– Phase II: Content approach for a RESTful health information

exchange (July-September 2012)


wiki.siframework.org/RHEx


5

The Project is Using…

■ Existing standards■ Focusing on refining existing standards to fit into the Nationwide

Health Information Network (NwHIN) portfolio

■ Pulling standards from the health and web domains

■ Aligns well with the Direct Project

■ Pilots■ Working to reduce ambiguity or oversights in the standards being

refined by the project

■ Conformance testing■ Providing a test framework so an independent party can implement

to RHEx profile for existing standards without using any project produced code


6

Why pursue a RESTful health exchange?

■ Because REST is the dominant design paradigm used on the world wide web today and offers a proven and scalable approach

■ To address an identified need– NwHIN Power Team recommended development of a

specification for RESTful exchange of health data (28 Sept 2011)

■ Power Team Comments REST is a style not a standard – not all RESTful implementations are the

same

REST can be secured with standards such as TLS and OAuth

REST specification would assure implementations are predictable and secured

■ RESTful approach could be another tool in NwHIN portfolio

– ONC Notice for Proposed Rule Making (NPRM) mentions possible inclusion of additional transport standards such as applying REST in Meaningful Use certification criterion (March 2012)

Etc.


7

Philosophy

■ Use the world wide web as it is used today– The REST architectural style is used widely on the web today– Use proven, open standards for identity management as well as

user and service authentication■ OpenID Connect for identifying and authenticating users

■ OAuth for service to service authentication

■ Apply constraints– Extend standards for the health IT domain– Where >1 implementation approach exists, select 1

■ Provide the framework for building services based on web technologies


Philosophy (graphical depiction)

8

1. Build on the Web of today

Additional Constraints

OAuthOpenID Connect

RESTfulArchitectural

Style

Health IT

Pil

ot

Use

Cas

e2. Use open standards

for identity and authentication

3. Apply constraints

5. Transparently share to allow innovation to occur

4. Pilot for risk mitigation


9

Overview

■ What is RHEx?■ Why pursue a RESTful exchange?■ Philosophy■ RHEx Implementation

– Core Technical Principles– RHEx Pilot Use Case– RHEx Phases– RHEx Security and Privacy– RHEx Stack– RHEx Products

■ NwHIN Harmonization■ Conclusion


Core Technical Principles

■ Internet Scale Access Management – Standards such as OAuth and OpenID have demonstrated

strong, scalable security at low cost

■ Granular and Addressable Data – Breaking healthcare information into small pieces accessible

by a URL enables secure, efficient access

■ Linking – When data is addressable, it can be linked on the web, allowing

humans and software to browse the web of links to view clinical contexts

■ Leverage HTTP – The protocol that drives the web offers a more robust, flexible

and scalable solution

10


Pilot Use Case: Consults/Referrals

■ Validated need and selected prototype use case via discussions with selected federal partners – The Department of Veterans Affairs: Identified consults as

possible use case– DoD Health Affairs: Confirmed value of use case and arranged

for further technical discussions– Telemedicine & Advanced Technology Research Group

(TATRC), U.S. Army Medical Research & Materiel Command (MRMC): Engaged in multiple discussions on consult/referral use case which led to pilot partnership

■ Drafted use case based upon these collaborations and existing Military Health System (MHS) and Health IT Standards Profile (HITSP) artifacts– Aligning with Transitions of Care (ToC) user stories

■ Partnering with TATRC on RHEx consult/referral pilot

11


12

Simplified Consult/Referral Use Case

consult resultsPCPConsulting Physician

consult request

Allows Primary Care Physician (PCP) and Consulting Physician to access and retrieve current, relevant portions of each other’s

records when they need them

URL-1 = Consult Requests Details URLURL-2 = Consult Results Details URL

URL-2Message

MessageURL-1

URL-1

URL-2

http://findicons.com/icon/77503/doctor_assistant?id=77512













13

Phases

■ Piloting RHEx approach in FY12 in two phases■ Phase 1: Security approach for a RESTful health information

exchange (April – July 2012)– Focus on securing web interactions– Use web/mobile friendly methods of exchanging identity

information and authorizing users via HTTPS– Seek community input on satisfactory and complete RESTful

security

■ Phase 2: Content approach for a RESTful health information exchange (July – September 2012)

■Expand pilot to show full benefit of a RESTful interaction and incorporate the content layer

■Seek community input on a structured approach to granular health data exchange


RHEx Security & Privacy

Safeguarding Access to Health Information

■ Use same trust model as Direct but implemented with Web Technologies

■ Communications secured with https

■ Use proven, open standards – OpenID for distributed Identity management

and user authentication

– OAuth for service-to-service authentication

■ Privacy is enforced at the provider location at the time the information is requested– Provides information needed for authorization determination

■ E.g., Extends standard profile information to add clinical role for use in enforcing access control

14


15

Stack

Content

Security

Transport

Encryption in Transit

Interface

Layer Purpose

Identity & Authentication

Content Payload

TLS/SSL

HTTP

Standards

CCDA

OpenID OAuth

HL7

V2C32

HTML DICOM …


16

Products

■ Testable, draft profiles for relevant, existing standards– OpenID Connect Profile

■ Constraints to limit choices/optionality

■ Extensions to convey healthcare specific identity information

– OAuth 2 Profile■ Constraints to limit choices/optionality

■ Extensions to enhance security

– Content Profile■ Granular format for health data

■ Reference Implementation– Open source code that can be used to implement a system that

adheres to the RHEx standards profiles

■ Independent test client– Open source software package that can validate conformance

of a service to RHEx profile of existing specifications


17

Overview

■ What is RHEx?

■ Why pursue a RESTful exchange?

■ Philosophy

■ RHEx Implementation

■ NwHIN Harmonization– NwHIN – RHEx: A Complementary Approach

– Exchanging data with RHEx and Direct

– NwHIN Portfolio and RHEx

■ Conclusion


NwHIN & : A Complementary Approach

■ A RHEx approach contributes NwHIN building blocks

– Could help accelerate NwHIN participation

■ Direct and a RHEx approaches can be used together– May use same user identity in both Direct and RHEx system– Direct messages may be used to securely send RHEx web links

among trusted partners■ No need to pass all the data with the email

■ Avoids mail server limits on attachment size

■ RHEx can be deployed along side Exchange / CONNECT supplementing service requests as needed

18


Exchanging data with and Direct

1. Dr. Miller Sends Secure Email with Link to Patient DataDr. Miller Direct

HISPDirectHISP

WebEndpoint

IdentityProvider

WebEndpoint

IdentityProvider

Health IT System

HISP = Health Information Service Provider

Dr. LowellMessage

Patient Data Link

3. Dr. Lowell Views Patient Data

2. Dr. Lowell Follows Link and Logs In with OpenID

HP1- EHR

Healthcare Provider #1 (HP1)

HP1- EHR Web View

Standard Email App

Healthcare Provider #2 (HP2)

Patient Data Link

Health IT System

19


Vocabulary & Code Sets

NwHIN Building Blocks

Content Structure

Transport

Security

Services

SNOMED-CT

Consolidated CDA

Care Summaries

UDDI-Certificate & Service Discovery

SOAP-Secure Web Services

Certificate Authority

X.509 - Digital Certificates

SMTP-Direct Based Exchange

DNS, LDAP-Certificate Discovery

Provider Directories

LOINC

Quality Reporting

ICD-10

Lab Results IG

Lab Results

RxNorm

HL7 v.2.5.1Public Health

Reporting

20

Diagram of NwHIN Portfolio 1.0

SAML

INTEROPERABILITY STACK

© 2012 The MITRE Corporation. All rights Reserved.For Internal MITRE Use.

21

Vocabulary & Code Sets

NwHIN Building Blocks

Content Structure

Transport

Security

Services

SNOMED-CT

Consolidated CDACare Summaries

UDDI-Certificate & Service Discovery

SOAP-Secure Web Services

Certificate Authority

X.509 - Digital Certificates

SMTP-Direct Based Exchange

DNS, LDAP-Certificate Discovery

Provider Directories

LOINC

Quality Reporting

ICD-10

Lab Results IG

Lab Results

RxNorm

21

NwHIN Portfolio 1.0 and

SAML

INTEROPERABILITY STACK

Consent\ Authorization

HTTPS / REST

OAuth & OpenID

Building Blocks a RESTful Health Exchange would add

Direct ExchangeRHEx

HL7 v.2.5.1Public Health

Reporting

© 2012 The MITRE Corporation. All rights Reserved.For Internal MITRE Use.

22

Conclusion

■ The RHEx project is investigating how proven web technologies may be used for simple, secure, and standards-based health information exchange– Will inform a path forward by identifying where:

■ Strong community consensus exists

■ Concerns or a lack of strong industry direction exists

■ This FY12 project seeks community engagement: – Visit the RHEx wiki for more information: wiki.siframework.org/RHEx

– Join the community discussion on Google Groups■ Also accessible through the wiki

– Participate in bi-weekly WebEx meetings (see S&I calendar)■ Thursdays, 11 am – 12 pm EDT (from June 28 – Sept 20)

– Share your perspectives■ Please share use cases where a RESTful approach may apply

■ Let us know if you would like additional information


http://wiki.siframework.org/RHEx

http://wiki.siframework.org/RHEx

https://groups.google.com/group/restfulhealthexchange

http://wiki.siframework.org/Calendar

Meeting Etiquette Please announce your name each time prior to making comments or suggestions during the call Remember: If you are not speaking keep your.

Documents

restful health exchange

mitre corporation

web technologies slide

existing standards

open standards

web of links

web domains

restful implementations