Justification and Objectives

  • Test scalable ecosystem trust models for security and privacy, including registration, authentication and authorization for cross-organization query through reusable credentials
  • Generate discussion about how to recognize certain classes of users, clients, or servers, reducing friction in ecosystem use of FHIR and working to develop best practices
  • Build on successes of previous work in Montreal at this track and in Atlanta

FHIR Version: This track prefers FHIR R4 but much of what's being tested involves OAuth interactions that transcend FHIR resource level of granularity.


** IMPORTANT: This track's Zoom Meeting will start THURSDAY at 9AM Eastern (not Wednesday). **
** The only connectathon activity planned for Wednesday is the HL7 Kick-Off call at 4PM Eastern **

Track overview: 

Zoom Meeting Room: https://zoom.us/j/3714589888 (Meeting ID: 371 458 9888)

Zulip: https://chat.fhir.org/#narrow/stream/179207-connectathon-mgmt/topic/Cross.20Organization.20Application.20Access

Clinical Input & Breakout Discussions

Please send questions and requested breakout topics to Julie or discuss (anytime now) in the track's Zulip stream. Hoping to schedule 1-2 breakout times each day (based on your input) for organized discussion on topics of interest. (See google slide deck for times.)

Track Lead

Julie Maas, julie@emrdirect.com 

Expected Participants

  • EMR Direct
  • Qvera
  • Health Intersections
  • Cerner
  • Particle Health
  • Anthem
  • One Medical
  • Carequality
  • Health Gorilla

  • Community Care HIE

  • Cigna
  • The Sequoia Project
  • NewWave
  • Cigna
  • Kaiser
  • Add your name here!

Track Orientation

Orientation: May 12 Carequality FHIR Technical Workgroup Call. Additionally, an introductory webinar from the May 2019 connectathon was hosted on 4/8/19 at 2pm Pacific (click for recording of webinar/track overview). Please Zulip or email any follow-up comments for track refining, suggestions, or questions to Julie.

Resources:


Endpoints for Track

ServerBase URLScenarios
EMR Direct Stage Serverhttps://stage.healthtogo.me:8181/fhir/r4/stageall scenarios
Carequality Directory Connectathon Serverhttps://connect.carequality.org/fhir-stu3/1.0.1/Scenario 1 (warmup to obtain endpoints)
Cerner Connectathon Serverhttps://fhir-ehr.stagingcerner.com/beta/0b8a0111-e8e6-4c26-a91c-5069cbc6b1ca/Scenario 1

System Roles

  • OAuth 2.0 server, ideally supporting dynamic discovery through UDAP Dynamic Client Registration and/or Tiered OAuth
  • OpenID Connect IdP server, ideally supporting discoverable identities through UDAP Tiered OAuth
  • FHIR server with built-in support for the above or able to rely on another OAuth server
  • FHIR client app capable of UDAP Dynamic Client Registration and/or Tiered OAuth


Scenarios

Scenario 1: Cross Organizational Trusted Application Authentication (Client Credentials Flow) *Focus of this track for May 2020*

Unlike Scenario 2, this scenario uses client_credentials grants with manual pre-registration of the client.

Actions:

0. Optional warmup exercise (results not recorded):

Registered(?) Client app obtains an access token from an open/unsecured FHIR server and uses the token to request patient resource

Client app obtains FHIR endpoint information from Directory server (directory server registration details to be added here)

  1. Client app registers dynamically with OAuth server using UDAP Dynamic Client Registration
  2. Client app authenticates to OAuth server using UDAP JWT-Based Client Authentication backed by a trusted client certificate and, if submitted authorization metadata meets authorization server's policy constraints, exchanges authorization code for an access token
  3. Client uses access token to request a patient resource

Preconditons:

Client pre-registers out of band manually beforehand, to obtain certificate for use in UDAP Dynamic Client Registration and UDAP JWT-Based Client Authentication (complimentary test certificates are available at https://www.emrdirect.com/subscribe-developer) 

OAuth server and client app support UDAP Dynamic Client Registration and UDAP JWT-Based Client Authentication (Client Credentials Flow)

Client has a certificate from an issuer that is trusted by the server

Client has a client_id provided by the OAuth server

Success Criteria:

Client app can obtain a patient resource from the target server; partial success for obtaining an access token as in step 2 

Swimlane Diagrams & Other Resources:

Scenario 2: Cross Organizational Trusted Application Authentication (Authorization Code Flow)

Actions:

  1. Client app registers dynamically with OAuth server using UDAP Dynamic Client Registration
  2. Client app obtains authorization code using standard OAuth 2.0
  3. Client app authenticates to OAuth server using UDAP JWT-Based Client Authentication backed by a trusted client certificate and exchanges authorization code for an access token
  4. Client uses access token to request a patient resource

Preconditons:

Client pre-registers out of band manually beforehand, to obtain certificate for use in UDAP Dynamic Client Registration and UDAP JWT-Based Client Authentication (complimentary test certificates are available at https://www.emrdirect.com/subscribe-developer) 

OAuth server and client app support UDAP Dynamic Client Registration and UDAP JWT-Based Authentication (Authorization Code Flow)

Client has a certificate from an issuer that is trusted by the server

Client has a client_id provided by the OAuth server

Success Criteria:

Client app can obtain a patient resource from the target server; partial success for obtaining a client_id via UDAP DCR; partial success for obtaining an access token; partial success for an anonymous DCR

Bonus Point:

Include a certification or endorsement

Swimlane Diagrams & Other Resources:

Diagram below for illustration purposes shows authorization_code grants with UDAP Trusted Dynamic Client Registration (NOTE: Authorization code flow is out of scope for May connectathon which will focus on client credentials flow):

Scenario 3:

Authentication using third party Identity Provider (IdP) via OpenID Connect (OIDC)

Action:

  • Client app initiates UDAP Tiered OAuth connection to OAuth server's authorization endpoint, identifying user's preferred OIDC IdP
  • OAuth server redirects user to IdP authorization endpoint (server acts as client of IdP)
  • User authenticates and authorizes access to identity information
  • OAuth server exchanges authorization code from IdP for token and id_token, optionally retrieves additional info from IdP's userinfo endpoint
  • OAuth server determines authority of user based on available identity information or pre-registration of the ID
  • Authenticated user authorizes client app to access FHIR resources
  • Client exchanges authorization code from OAuth server for token, and access FHIR resources

Preconditions:

OAuth server (securing FHIR resources) and client app support UDAP Tiered OAuth

Client is registered with OAuth server for authorization_code flow

OAuth server is registered with IdP for authorization_code flow

Success Criteria:

Client app can access FHIR resources

Bonus points:

OAuth server registers dynamically with IdP using UDAP DCR

Client app registers dynamically with OAuth server using UDAP DCR

Scenario 4: Validation of FHIR endpoint managing organization in multi-tenant environment

Action:

Client app validates the identity and/or trustworthiness of endpoint/TBD

Flow continues, using information from previous step (happy path: user authenticates and authorizes client app to access FHIR resources)/TBD

Precondition:

FHIR endpoint certificate advertisement, demonstrating control of key

Success Criteria:

Client app can access FHIR resources/TBD

Scenario 5: Patient matching using OpenID Connect account as an attribute

For discussion: How can an OpenID be included as a searchable attribute for a patient?

For example, could store as identifier with:
Identifier.type = http://www.udap.org/fhir/CodeSystem/identifier-authenticator | oidc-sub
Identifier.system = Issuer Identifier URI
Identifier.value = Subject Identifier assigned by Issuer

e.g.

{
"resourceType":"Patient",
...
"identifier": [
  {
    "type": {
      "coding": [
        {
          "system":"http://www.udap.org/fhir/CodeSystem/authentication-identifier",
          "code":"oidc-sub",
          "display":"OIDC Subject Identifier"
        }
      ]
    },
    "system":"https://as.healthtogo.me",
    "value":"1234567"
   },
   ...
 ],
 ...
}

Action:

Search on OpenID subject identifier

e.g. GET [base]/Patient?identifier=https://as.example.com/issuer1|1234567

Precondition:

The data holder confirmed the binding of an OIDC subject identifier to the person named in a Patient (or equivalently to a Practioner, Person, or RelatedPerson) resource using a suitable registration process before adding the identifier.

Success Criteria:

Client app can access FHIR resources for the correct patient linked to the OIDC subject identifier.

Bonus point:

Search using $match operation

TestScript(s)

Indicate any test scripts that will be used to help verify system behavior

Security and Privacy Considerations

Identify any expectations around security (e.g. will TLS, mutual-TLS, OAuth, etc. be required to participate

  • No labels