HIT Standards CommitteePrivacy and Security Workgroup Discussion of NwHIN Power Team Recommendations

August 6, 2013

1

Agenda

11:30 am Call to Order/Roll CallMichelle Consolazio, ONC

11:35 am Welcome and Agenda ReviewDixie Baker and Walter Suarez, Co-Chairs

11:40 am Review of NwHIN Power Team Recommendations Dixie Baker and David McCallie, NwHIN Power Team Co-Chairs

11:50 am Discussion of Draft Points of Agreement and Responses to Submitted Questions and Comments All

12:40 pm Consensus Recommendations to NwHIN Power TeamAll

12:55 pm Public Comment

1:00 pm Adjourn

2

NwHIN Power Team Overarching Conclusion

Secured RESTful transport (HTTPS)+

OpenID Connect authentication+

OAuth2 authorization+

FHIR healthcare content

a safe and appropriate set of standards to use as building blocks

for more complicated healthcare applications

3

NwHIN Power Team Recommendations (1 of 2)

• Recommend that ONC support and encourage the development and piloting of BB+, FHIR, and RHEx

• BB+ “Pull” focuses on a specific, identified need to enable a consumer to access their own health information or to authorize a third-party application to do so– Emerging standard whose development should be supported and

early pilots encouraged– Encourage EHR vendor participation– No known alternatives that address this need

• FHIR is highly likely to become a key next-generation content standard for healthcare– Need for FHIR CCDA (being developed)– Appropriate as content standard for both BB+ and RHEx

4

NwHIN Power Team Recommendations (2 of 2)

• RHEx is a useful demonstration of how HTTPS, OpenID Connect, OAuth2, and FHIR can be used together to support robust, but simple healthcare exchange– Commendable response to NwHIN Power Team’s

recommendation for a RESTful complement to Direct and Exchange

– Responds to industry need for a simple means of transmitting large healthcare data objects (e.g., images) that cannot be accommodated by Direct

– Encourage replacement of hData with FHIR– Given the flexibility of the RHEx architecture and the optionality

available from OAuth2, profiles based the RHEx initiative may be more appropriate candidates as national standards than the full body of work

5

Readiness Evaluation Readiness Evaluation

Emerging Standards

Pilots

National Standards

Adoptability

Mat

uri

ty

Low Moderate High

Lo

w

M

od

era

te

H

igh

HTTPS

OAuth2

OpenID Connect

RHEx FHIR

“Pull”

National Standards

Pilots

Emerging Standards

Red Type = building blocksWhite box = projects reviewed 6

Draft Points of Agreement

Agree that secured RESTful transport (HTTPS), OpenID Connect, OAuth2, and FHIR can be used together to build safe healthcare applications Some Privacy and Security Workgroup members are currently working

on the development of profiles using these standards, including BB+, RHEx, and IHE profiles for Mobile Health Documents (MHD) and Internet User Authentication (IUA)

Agree that BB+ holds potential as a national implementation specification for the 2016 Edition, but further development and piloting are needed for “Pull” capability

Agree that RHEx is a useful demonstration of how these standards can be used together to support robust, but simple healthcare exchange

7

Submitted Questions/Comments and Draft Responses

Several other security-relevant profiles built on OAuth2 may be worthy of consideration as part of the NwHIN Power Team’s recommendations:

User Managed Access (UMA), being developed by Kantara Initiative (DRAFT)

IETF SAML 2.0 Bearer Assertion Profile for OAuth2 (DRAFT)

IETF OAuth 2.0 Dynamic Client Registration Protocol (DRAFT)

None of these specifications is sufficiently mature to be included in the current NwHIN Power Team’s recommendation. May need to revisit these in the future, if specific healthcare use-cases emerge.

8

Submitted Questions/Comments and Draft Responses

BB+ profile has a stub for patient authentication that ignored in the profile. Should BB+ add patient authentication?

This is not a “stub.” The BB+ profile explicitly assigns responsibility for patient authentication to the holder of data being “pulled.” This is done through a BB+ redirect to the data provider’s patient authorization service, which will frequently be the same as the provider’s patient portal login screen. This is a sound approach as it allows the data-holder to enforce its own policies around patient authentication and authorization.

Providers should exercise care in provisioning patient portal accounts, but specific level-of-assurance requirements are best left to policy decisions.

9

Submitted Questions/Comments and Draft Responses

• IHE has developed an Internet User Authentication (IUA) profile, informed by the RHEx Project, that provides a user-context specification compatible with the current use of the Security Assertion Mark-up Language (SAML) to pass security assertions using the Secure SOAP Transport included in the 2014 Edition Standards and Certification Criteria. The IUA profile also supports a JSON Web Token (JWT) that is convertible, and defines recommended “user context” data fields to be included in the assertions. Should the IHE IUA profile be included in the NwHIN Power Team’s recommendation?

The IUA profile appropriately constrains and structures OAuth2 tokens to support sharing of SAML assertions within SOAP-based environments. We recommend that IUA be added to the NwHIN Power Team’s recommendation for use in environments that require coexistence with existing profiles based on IHE constrained SAML assertions. 10

Submitted Questions/Comments and Draft Responses

• OAuth2 specifies a process called Dynamic Client Registration by which an application registers with a data provider before it is able to pull data from that provider. BB+ goes a step further to include a Registry Service through which the trustworthiness of an app is established based on its ability to protect the registration token and client secret returned by the data provider. BB+ considers “open registration” (i.e., not registered with the Registry Service) appropriate only for new and experimental apps, and suggests displaying a warning with these apps. Should all BB+ apps be required to be registered with the Registry Service? What level of minimal assurance is reasonable and appropriate for BB+ Pull apps?

Requiring a specific Level of “App Assurance” is a policy question, not technology. We recommend ONC ask the Privacy and Security Tiger Team to address this question as input into the BB+ Pull development effort.

In the mean time, defining a mechanism that would support such a registry if and when policy requires it is an reasonable strategy. 11

Submitted Questions/Comments and Draft Responses

Should any requirements or constraints about OAuth2 access token format (and token signing) be recommended?

For Blue Button+ Pull?

For the overall recommendation of OAuth2 as a component of a safe set of standards?

The Privacy and Security Workgroup need more detail and discussion around the role of token’s in OAuth2 and BB+ (Josh Mandel will lead this discussion)

12

OAuth2: App vs. Data Holder Boundaries

http://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/

App

Data Holder

13

OAuth2: App vs. Data Holder Boundaries

http://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/

App

Data Holder

Structured Tokensmost relevant here(thus: not needed for BB+)

}14

Consensus Recommendations to NwHIN Power Team

P&S WG Conclusions

15