1 of 17

CDS Hooks

HL7 WGM Jan 2018 Connectathon

Friday, January 26, 2018

New Orleans, LA

2 of 17

Agenda

Introductions and plans for connectathon

Security assessment summary

1.0 release plan

Issues for tonight

  • #119 - Move patient & encounter id to hook specific context
  • #87 - Guidance for where CDS Services can retrieve the EHR's public key

�Post 1.0 feedback & plans

3 of 17

Connectathon

  • Logistics
    • All-day Saturday & Sunday (starts at 9am but arrive early)
    • St. Charles Ballroom (3rd floor)
  • 42 CDS Hooks participants - a new record!!!
    • EHRs, CDS Service Providers, Healthcare organizations
  • 1.0 feedback is imperative
  • Security implementation experience
  • Lots of disparate use cases (Infobutton, opioids, genetics, etc)

Meet & talk with your new friends, hack, and have fun!

4 of 17

Argonaut Security Assessment

  • The Argonaut Project funded a 3rd party security review & assessment, ongoing since October 2017�
  • Dixie Baker, PhD is performing the assessment and also did this for SMART on FHIR�
  • TL;DR - The majority of changes are just documentation improvements :-)

5 of 17

Security Assessment Changes

6 of 17

Documentation Improvements

  • Articulate risks and potential threats so that implementers understand them and can make their own choices based upon their tolerance of risk�
  • Strengthen conformance verbiage where appropriate�(MUST, SHOULD, MAY, etc)�
  • Document each request/response field with REQUIRED or OPTIONAL

7 of 17

fhirAuthorization - Add new subject parameter

"fhirAuthorization" : {

"access_token" : "some-opaque-fhir-access-token",

"token_type" : "Bearer",

"expires_in" : 300,

"scope" : "patient/Patient.read patient/Observation.read",

"subject" : "the-cds-service-oauth2-client-id"

}

8 of 17

JWT Signatures

  • From implementer feedback (post Sept 2017 Connectathon) and the Argonaut security review, it is clear this is an issue we need to tackle for 1.0

  • Plan is to align our strategy with that of the SMART Backend Services, which also leverages signed JSON web tokens (JWT)

  • <More details on a proposed implementation later in this meeting>

9 of 17

1.0 Release Plans

10 of 17

1.0 Release Plans

  • Finalize security assessment (early February)
  • HL7 Jan 2018 WGM feedback (‘informal ballot’ - Now!)
  • Wrap-up remaining 1.0 milestoned issues

1.0 release in Q1 2018

11 of 17

Issues for discussion

12 of 17

#119 - Move patient_id and encounter_id to context

{� "hookInstance" : "some-uuid",� "fhirServer" : "https://fhir.example.org",� "hook" : "patient-view",� "user" : "Practitioner/example",� "patient" : "123",� "encounter" : "456",� "prefetch" : { .. },� "context" : { ... },� "fhirAuthorization" : { ... }�}

{� "hookInstance" : "some-uuid",� "fhirServer" : "https://fhir.example.org",� "hook" : "patient-view",� "user" : "Practitioner/example",� "patient" : "123",� "encounter" : "456",� "prefetch" : { .. },� "context" : { "patient" : "123",� "encounter" : "456"},� "fhirAuthorization" : { ... }�}

13 of 17

#87 - Specify JWT public key > JWT Changes

JSON Web Token (JWT):

Header:�add "kid": "some-opaque-identifier"��Payload (no changes):�{� "iss": "https://fhir-ehr.example.com/",� "sub": "client_id",� "aud": "https://cds.example.org/cds-services/some-service",� "exp": 1422568860,� "iat": 1311280970,� "jti": "ee22b021-e1b7-4611-ba5b-8eec6a33ac1e",�}

14 of 17

#87 - Specify JWT public key > JWKs

Issuer makes JWKs available at {iss}/.well-known/jwks.json

JWK endpoint conforms to RFC 7517, JSON Web Key (JWK). Example:

{� "keys": [� {� "kty": "EC",� "crv": "P-256",� "kid": "some-opaque-identifier",� "x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",� "y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0"� }� ]�}

15 of 17

#87 - Specify JWT public key > Summary

  • Initially intended to be addressed post 1.0, the reality is that all implementers need a solution today�
  • SMART’s use of OpenID Connect already requires JWTs and JWKs�
  • SMART Backend services leverage signed JWTs too and we want to align our strategy�
  • Adopting two existing IETF standards allows us to leverage existing OSS libraries and work
    • JSON Web Signature (rfc7515)
    • JSON Web Key (rfc7517)

16 of 17

Post 1.0 Feedback &

Open Discussion

17 of 17

Post 1.0 Feedback & Open Discussion

  • Decisions?
  • Additional use cases? (opioids? radiology?)
  • Anything else?
  • Continue to log issues on gitHub