CDS Hooks HL7 WGM Jan 2018 CDS Working Group Tuesday, January 30, 2018 New Orleans, LA

Agenda Connectathon summary Argonaut security assessment summary Specification changes 1.0 release plan Post 1.0 feedback & plans

Connectathon Summary 42 CDS Hooks participants - a new record!!! EHRs, CDS Service Providers, Healthcare organizations Excellent 1.0 feedback - several issues logged & changes made Excellent security implementation feedback! Lots of disparate use cases (Infobutton, opioids, genetics, etc)

Univ of Utah Opioid CDS Service

Infobutton CDS Service

medication-prescribe hook in Cerner

Argonaut Security Assessment

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 :-) TL;DR = Too Long Didn’t Read

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

fhirAuthorization - Add new subject parameter "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" } subject client_id of authorized assessor (CDS Service) for which the access token is being requested

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)

#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", }

#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" } ] }

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

Notable Specification Changes

#109 - Hooks define their own context Lesson learned: Code and examples are more important than specification doc :P Context is now an object, the contents of which defined by each hook Specification Sandbox Examples Implementers Context Data Type object array

#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" : { "patientId" : "123", "encounterId" : "456" }, "fhirAuthorization" : { ... } }

#151 - Clarity around prefetch tokens Today: {{Patient.id}} {{User.id}} Proposed: Hooks indicate which first-level fields can be prefetch tokens Prefetch tokens have a defined naming convention {{user}} {{context.patientId}} {{context.encounterId}}

1.0 Release Plans

1.0 release in Q1 2018 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

Post 1.0 Feedback & Open Discussion

Post 1.0 Feedback & Open Discussion Decisions? Additional use cases? (opioids? radiology?) Anything else? Continue to log issues on GitHub