Testing Scenario: | Breakout Sessions:FAST National Directory (Saturday, 10-11 AM PT, Room TBA) - Reserved by Ming Dunajick/Lantana FAST Versioning Breakout (Saturday, 11:00 - 12:00 PM PT, Room TBA) - Reserved by Mario Hyland/AEGIS FAST Identity/Patient Matching (Sunday, 10-11 AM PT, Room TBA) - Reserved by Aaron Nusstein/Lantana FAST National Directory (Sunday, 12:30-2 PM PT, Room TBA) - Reserved by Ming Dunajick/Lantana UDAP Security (Sunday, 1-1:30 PM PT, Room TBA) - Reserved by Aaron Nusstein/Lantana WGM - FAST Digital Identity & Patient Matching (Tuesday, 11:00 - 12:30 PT, Estate Board Room) - Reserved by Aaron Nusstein/Lantana 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 + trust policy logic (validating requestor's certificate etc.) 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 + trust policy logic to validate responder's Server Metadata
- 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 including trust policy logic and matching capability
- Registration server
- Auth server
- Token endpoint
- Certificate
- Serviced by Intermediary when Intermediary is in scope
Organization C (Intermediary) - Certificate
- Trust policy logic to validate trust with other participants per UDAP Security
- 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 with embedded JWT-Based Authentication B2C and associated trust policy – 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 trust policy engines to trust applicable issuers and (if needed) intermediaries per UDAP Security; participants have implemented their respectful roles in matching capability per FAST Identity 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 + trust 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 community-wide or additional local trust 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 + trust 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. In variation "2b", the match request may have context of multiple organizations (e.g. in a TEFCA context) so that the fullURL element of each matching patient is relevant. | 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 verified demographics in L1 (or at least L0, since this is B2B) $match request and responder's system appropriately scores match input and uses within matching capability
- [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) (if Org A credentials trusted per policy and match capability returns results-per UDAP Security and FAST Identity) 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 (if participants pass trust validation) | 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
Bonus Point: Organization A is using an untrusted, expired, or revoked certificate and Organization B therefore does not allow registration
Bonus Point: Organization A's signed JWT validates and its certificate is otherwise good but it does not chain to a trusted issuer so Organization B therefore does not allow registration
Bonus Point: Organization A's signed JWT does not validate as it is signed with a key other than the one presented so Organization B therefore does not allow registration
| Organization A as Client App capable of UDAP Security B2C |
|
|
| | Organization B as Data Holder capable of UDAP Security B2C (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) - Nominal case (Tiered OAuth not yet implemeted): authenticate user with credentials tightly coupled to data holder's system
- Validate 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 (nominal case possible without this role) |
|
| 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, if validated per trust policy, are scored by responder's system and used along with Client's credentials as input to data holder's matching capability
- 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
|
|
|
|
|
|
|
|
|
