Testing Scenario: | Actors:National Directory Endpoint directory - UDAP FHIR Server with Server Metadata
- Certificate
- Collects Attestations → directory writes
- Directory read access - some public and some sensitive endpoints
- Auth server with UDAP JWT-based client authentication + policy logic for writes and sensitive data access
Organization A - UDAP FHIR Client (Requestor) - Client capable of UDAP Tiered OAuth, UDAP Dynamic Client Registration, UDAP JWT-based Authentication
- Requests FHIR data
- Certificate
Organization B - UDAP FHIR Server (Responder) - UDAP Server Metadata
- Implements Server side of UDAP Dynamic Client Registration and UDAP JWT-Based Authentication
- Registration server
- Auth server
- Token endpoint
- Certificate
- Serviced by Intermediary when Intermediary is in scope
Organization C (Intermediary) - Certificate
- When present, performs some of the roles for B
Patient A - OpenID Connect credentials from Organization A
- Has received care at Organization B
Identity Server (Supports IdP functions of FAST Security UDAP Tiered OAuth – Authenticate a user and provide an ID Token – plus one or more of the following capabilities according to role) - Remote (online) Identity verification
- Optional: Additionally support an in-person Identity verification process
- ID Token with attributes as per FAST Identity IG
- Patient Matching as per FAST Identity IG to determine whether user already exists on IdP system
Functions to test:Prerequisites: Organizations have test certificates and have configured their policy engines to trust applicable issuers and (if needed) intermediaries 1. Connect to the National Directory and make a public endpoint query, then attest to organizational information and endpoints Scenario Steps | Roles | Components Needed | Documentation | Value |
---|
A. Find an Endpoint: Access unsecured directory to identify public URL for a different organization (without intermediary) - TODO: Resources exist to help with this and will be populated here.
| Distributed workflow directory | |
|
| National Directory |
|
|
| B. Attest to Data: Register (UDAP Security - Dynamic Client Registration) and Authenticate (UDAP Security - B2B) to Directory and attest, writing their data (TODO: insert link to Directory IG) to directory - TODO: Client sample code/examples needed; server RI availability TBD; implementations can test against UDAP Test Tool tests
- Success criteria: data is successfully written to directory
| Distributed workflow directory | - UDAP FHIR Server with Server Metadata
- Certificate
- National Directory Attestation → directory writes
- Auth server with UDAP JWT-based authentication + policy logic for writes
|
|
| National Directory |
|
|
| C. Directory to Directory Exchange: Register (UDAP Security - Dynamic Client Registration) and Authenticate (UDAP Security - B2B) to the National Directory, accessing sensitive data (TODO: insert link to Directory IG) to directory - TODO: Allow and validate writes by trusted clients in Directory RI (Practitioner, PractitionerRole, Restriction)
- Per policy, some orgs may not be authorized to write sensitive data, or to write data at all
| Distributed workflow directory | - UDAP FHIR Server with Server Metadata
- Certificate
- National Directory Attestation à directory writes
- Auth server with UDAP JWT-based authentication + policy logic for writes and sensitive data access
|
|
| National Directory |
|
|
|
2. Patient A visits Organization A for an appointment; Organization A identity proofs Patient A and collects information during patient registration - Prerequisite: other testing participants know Patient A details, which can be shared on this worksheet
- Prerequisite: systems agree on a target "fake" Patient A and associated demographics (for example, Alice Newman)
- Minimum attributes collected:
- Full legal name (the name that the person was officially known by at the time of issuance of the supporting evidence; not permitted are pseudonyms, aliases, an initial for surname, or initials for all given names)
- home address
- date of birth
- email address
- mobile number (preferred; if a mobile number is not available, collect an alternative number for the individual)
Scenario Steps | Roles | Components Needed | Documentation | Value |
---|
A. Verify Patient A's identity at a target level of assurance (for example, IAL1.8) as per Guidance on Identity Assurance within Identity IG - Patient A is sent through a workflow using demographics they specified above plus acceptable identity evidence required to meet the desired level
| Patient A (Individual) |
|
|
| Organization A as Identity Service capable of FAST ID Digital Identity |
|
| B. Demographics (and later: optional verification status) are ready to be used in a $match request as per UDAP Security, Identity IG | Organization A as Client capable of FAST ID Digital Identity |
|
|
| Organization B as Data Holder populates their system with information about this patient for use in later scenarios (Scenario Prerequisite only; Org B has no active role in this scenario) |
|
| C. Bonus point: create a Digital Identifier with associated OpenID Connect Credential and authenticator for Patient A as per Digital Identity within Identity IG | Organization A as Identity Service |
|
|
| D. Bonus point: Identity Service indicates to Client App exactly which demographics were verified at specified community IAL | Organization A as Identity Service |
|
|
| E. Bonus point: include private Digital Identifier only in trusted transactions and when authorized by Patient A | Organization A as Identity Service |
|
|
|
3. Organization A has a need for information held by Organization B. Organization B uses an intermediary (Organization C) to receive FHIR requests on its behalf. Note: Intermediary w/ transparent reverse proxy only; this same workflow can also be tested without an intermediary Scenario Steps | Roles | Components Needed | Documentation | Value |
---|
A. Organization A accesses endpoint directory (insert Directory IG link) to identify public URL for Organization B - Organization B’s public endpoint resolves to intermediary, Organization C leveraging Hybrid/Intermediary Exchange IG to service Organization B's FHIR requests
- Track prep: Abbie show accessing public endpoint
| Organization A |
|
|
| Distributed workflow directory |
|
| Organization C - Intermediary |
|
| B. Bonus point: Register (UDAP Security - Registration) and Authenticate (UDAP Security - Authorization and Authentication - B2B) to Directory and obtain a sensitive endpoint (e.g. women's shelter, other record not publicly listed) - TODO: Populate and secure a sensitive endpoint in Directory RI (Practitioner, PractitionerRole, Restriction)
| Organization A as Client App capable of UDAP Security B2B |
|
|
| Distributed workflow directory capable of UDAP Security B2B |
|
|
| C. Organization A dynamically registers at Organization B public endpoint (UDAP Security - Registration) - Organization B’s public endpoint resolves to intermediary leveraging Hybrid/Intermediary Exchange IG
- FHIR server answering initial discovery request is going to provide the location of its registration endpoint as publicly accessible URL
| Organization A as Client App capable of UDAP Security B2B |
|
|
| Organization B as Data Holder capable of UDAP Security B2B (itself or as serviced by Org C) |
|
| Organization C - Intermediary |
|
| D. Org A requests access token for Org B's public endpoint (UDAP Security - Authorization and Authentication - B2B layered onto Hybrid/Intermediary Exchange IG) - Validating that the listing obtained from the Directory is in fact from the entity via UDAP Server Metadata IG (to confirm with Exchange this is correct?)
| Organization A as Client App capable of UDAP Security B2B |
|
|
| Organization B as Data Holder capable of UDAP Security B2B (itself or as serviced by Org C) |
|
| Organization C - Intermediary |
|
| E. Organization A requests $match against Organization B’s public endpoint (FAST Identity) - Intermediary receives match request and routes to Organization B’s private endpoint
- Bonus point: request includes Level 1 IDI
- Bonus point: response includes Responder’s System Match Output Quality Score from Identity IG in lieu of locally-computed match confidence
- Bonus point: requestor provides insufficient demographics and is returned with an informative error and no results
- Bonus point: requestor provides demographics with verification status in $match request and responder's system appropriately scores match input and uses as input to response policy engine
- [What other aspects of ID/matching IG should be tested?]
| Organization A as Client App capable of UDAP Security B2B + FAST ID Patient Match and associated with an Identity Service capable of FAST ID Digital Identity |
|
|
| Organization B as Data Holder capable of UDAP Security B2B and FAST ID Patient Match (itself or as serviced by Org C) |
|
| Organization C - Intermediary |
|
| F. Organization B responds with match(es) & associated patient ID(s) and intermediary routes response back to Organization A | Organization A (") |
|
|
| Organization B (") |
|
| Organization C - Intermediary (") |
|
| G. Organization A requests patient information from Organization B public endpoint, using returned patient ID - Intermediary receives request and routes to Organization B’s private endpoint
| Organization A (") |
|
|
| Organization B (") |
|
| Organization C - Intermediary (") |
|
| H. Success criteria: Organization A obtains health data from Organization B | Organization A (") |
|
|
| Organization B (") |
|
| Organization C - Intermediary (") |
|
|
4. B2C scenario with UDAP Tiered OAuth, with Identity IG's Digital Identity including an OpenID Connect credential (with an authenticator), and Digital Identifier within the user profile Workflow similar to Scenario 3 except a Client application's access to data at Organization B is authorized by Patient A in consumer-directed exchange via UDAP Tiered OAuth and with JWT-based Authentication B2C (instead of B2B) Scenario Steps | Roles | Components Needed | Documentation | Value |
---|
A. Organization A accesses endpoint directory (National Directory Endpoint Query) to identify public URL for Organization B - Organization B's public endpoint resolves to Intermediary, Organization C leveraging National Directory Exchange IG to service Organization B's FHIR requests
- Show accessing public endpoint
| Organization A Client App |
|
|
|
|
|
| B. Bonus point: Register (UDAP Security - Registration) and Authenticate (UDAP Security - Authorization and Authentication - B2B) to Directory and obtain a sensitive endpoint (e.g., women's shelter, other record not publicly listed) - Prerequisite: Directory RI has populated and secured a sensitive endpoint (Practitioner, PractitionerRole, Restriction)
| Organization A as Client App capable of UDAP Security B2B |
|
|
| Directory as Data Holder capable of UDAP Security B2B |
|
| C. Organization A dynamically registers at Organization B endpoint (UDAP Security - Registration) - Organization B's endpoint resolves to intermediary leveraging National Directory Exchange IG
- FHIR server answering initial discovery request is going to provide the location of its registration endpoint as publicly accessible URL
| Organization A as Client App capable of UDAP Security B2B |
|
|
| Organization B as Data Holder capable of UDAP Security B2B (itself or as serviced by Org C) |
|
| Organization C - Intermediary |
|
| D. Organization A, with patient A as end user authorizing the client app, requests access token for Organization B's endpoint (UDAP Security - Authorization and Authentication - B2C layered onto National Directory Exchange IG); Organization B authenticates Patient A using UDAP Tiered OAuth and Digital Identity issued by Organization A (FAST Identity) - Validating that the listing obtained from the Directory is in fact from the entity via UDAP Server Metadata IG
- Bonus Point: Organization B has records for Patient A via exact match on Patient A's Digital Identifier (e.g., Patient A had previously registered their Digital Identity and this Digital Identifier issued by Organization A at Organization B)
- Bonus Point: Organization B has records for Patient A via single high confidence match on demographics in the ID token from Organization A commensurate with those required in IDI Level 1
| Organization A as Client App capable of UDAP Security B2C and Patient A as end user |
|
|
| Organization B as Data Holder capable of UDAP Security B2C |
|
| Identity Service capable of Tiered OAuth and Digital Identity |
|
| E. Organization B returns token response and (via intermediary, if any) routes back to Organization A
| Organization A as Client App capable of UDAP Security B2C and Patient A as end user |
|
|
| Organization B as Data Holder capable of UDAP Security B2C |
|
|
|
|
| F. Organization A requests health data from Organization B's endpoint - Intermediary (if any) receives request and routes to Organization B's private endpoint
- Bonus Point: ID token includes insufficicent demographics or Digital Identifier is unknkown and is returned with an informative error and no results
- Bonus Point: Identity Service-provided demographics within ID token are scored by responder's system and used along with CLient's credentials as input to data holder's policy engine
- Bonus Point: Organization B performs other out of band interaction with Patient A that enables use of their Digital Identity to access health data
| Organization A as Client App capable of UDAP Security B2C and Patient A as end user |
|
|
| Organization B as Data Holder capable of UDAP Security B2C |
|
|
|
|
| G. Success Criteria: Organization A obtains health data from Organization B | Organization A as Client App capable of UDAP Security B2C and Patient A as end user |
|
|
| Organization B as Data Holder capable of UDAP Security B2C |
|
| H. Bonus Point: The OAuth sign in page allows user to authorize sharing of the Digital Identifier per Identity IG or other PII from user profile directly to Organization B | Identity Service capable of Tiered OAuth and Digital Identity |
|
|
|
|
|
|
| I. Bonus Point: OIDC user profile includes account-level identity and/or authentication level of assurance | Identity Service capable of Tiered OAuth and Digital Identity |
|
|
|
|
|
| J. Bonus Point: OIDC user profile includes verified demographics as in Identity IG | Identity Service capable of Tiered OAuth and Digital Identity |
|
|
|
|
|
|
NOTE: This scenario's steps a-e and the identity portion of f.iii are also exercised in similar workflows, such as when 1) Partner Role: a system's own security environment, OAuth and possibly also identity verification services are outsourced to a trusted credential management partner serving as the UDAP Tiered OAuth IdP or 2) TEFCA Identity Services: a third party IdP is used for identity verification and authentication of Participant Users and indicates a unique Digital Identifier and/or verified demographics per FAST Identity IG directly to a QHIN's UDAP Server.
5. Test sharing demographic attributes within an authorization extension object in UDAP Security's JWT-based authentication B2B (and as per Carequality FHIR IG and UDAP Security IG + FAST Identity IG) in a Patient Access workflow not requiring patient credentials at the responder’s organization Scenario Steps | Roles | Components Needed | Documentation | Value |
---|
A. Organization A accesses endpoint directory (National Directory Endpoint Query) to identify public URL for Organization B - Organization B’s public endpoint resolves to intermediary, Organization C leveraging National Directory Exchange IG to service Organization B's FHIR requests
|
|
|
|
|
|
|
| B. Bonus point: Register (UDAP Security - Registration) and Authenticate (UDAP Security - Authorization and Authentication - B2B) to Directory and obtain a sensitive endpoint (e.g., women's shelter, other record not publicly listed) |
|
|
|
|
|
|
| C. Organization A dynamically registers at Organization B public endpoint (UDAP Security - Registration) - Organization B’s public endpoint resolves to intermediary leveraging National Directory Exchange IG
- FHIR server answering initial discovery request is going to provide the location of its registration endpoint as publicly accessible URL
|
|
|
|
|
|
|
| D. Organization A requests access token for Organization B's public endpoint (UDAP Security - Authorization and Authentication - B2B) with verified minimum required demographics for the carequality_user that uniquely specify an individual that is the patient user (FAST Identity) included in the Authorization Extension Object (Carequality FHIR IG) - Validating that the listing obtained from the Directory is in fact from the entity via UDAP Server Metadata
- Intermediary receives token request and routes to Organization B private endpoint
|
|
|
|
|
|
|
| E. Organization B returns an access token if the user is an exact match and intermediary routes response back to Organization A; otherwise an error is returned - Bonus point: requestor provides insufficient demographics and is returned with an informative error and no results
- Bonus point: requestor includes Digital Identifier in Authorization Extension Object and responder's system matches on this identifier on its own or in addition to other demographics
|
|
|
|
|
|
|
| F. Organization A performs a $match operation against Organization B public endpoint and obtains patient ID(s) - Organization B will only return patient ID(s) for patients that the user is authorized to see
|
|
|
|
|
|
|
| G. Organization A requests health data for the patient from Organization B public endpoint |
|
|
|
|
|
|
| H. Intermediary receives request and routes to Organization B private endpoint - Success criteria: Organization A obtains health data from Organization B
|
|
|
|
|
|
|
|
|
2 Comments
Cait Ryan
For those interested in using the Touchstone Proxy feature, please watch the following videos:
Set up and walk-through of AEGIS's Touchstone Testing Platform operating as a proxy using the Peer-to-Peer feature to test and capture FHIR exchanges between a client and server with and without OAuth by Richard Ettema, Lead Developer and Sr. Technical Architect, AEGIS’ Touchstone Testing Platform.
High-level walk-through of FHIR Test Server set up and configuration using AEGIS' Touchstone Testing Platform and where to find the proxy data used in Conman Connectathon Manager to advertise the proxy connection for Peer-to-Peer/Proxy Testing by FHIR Clients at HL7 FHIR Connectathons and related events, by Wendy Gereke, Engagement Manager, AEGIS’, Inc.
Julie Maas
Presentations from Breakout Sessions
FAST Infrastructure - Dynamic Registration (B2B/B2C) & B2B Auth; Reusable Digital Identities (B2C):
FAST Infrastructure - Matching options beyond Patient $match (B2B):