Short Description

Test end-to-end FAST solutions (Security, Identity, Directory, Exchange)

Long Description

FAST infrastructure supports requirements in the CMS rules for Interoperability and Patient Access as well as Reducing Provider and Patient Burden

Type

Test Implementation Guides

Track Lead(s)

Aaron Nusstein and Adam Phillips

Track Lead Email(s)

aaron.nusstein@lantanagroup.com and adam.phillips@lantanagroup.com

Specification Information

2022-05 FAST Security & Identity

2022-05 FAST National Directory US Realm

2022-01 FAST - Hybrid/Intermediary Exchange

Reference Implementations (Security, Directory, Identity): https://github.com/HL7-FAST/

Endpoint Information:  https://docs.google.com/spreadsheets/d/1awkXXQaeuRv5ysLo8R6f1fpfBlpTJGfSPK4xRjsai7M/edit#gid=820206691

Reference Implementations

Directory

Security

Identity

Additional Resources:

Touchstone:  https://touchstone.aegis.net/touchstone/

Touchstone Docs: https://touchstone.aegis.net/touchstone/userguide/html/index.html

Touchstone Support:  touchstone_support@aegis.net

ConMan for Connectathon 32 - http://conman.clinfhir.com/?event=con32

External IP Finder: https://www.whatismyip.com/

Prior Presentations on Touchstone's Test System Setup and Peer-to-Peer/Proxy Features:

  1. FHIR Test Server Setup for Peer-to-Peer/Proxy Testing in Touchstone & Connectathon Manager (ConMan) - YouTube
  2. FHIR Testing - Using Touchstone's Peer-to-Peer/Proxy Features to Capture and Test FHIR® Exchanges - YouTube

Call for participants

Providers, EHR Vendors, Payers, Intermediaries (e.g., HIEs, Clearinghouses, etc.)

Zulip stream

https://chat.fhir.org/#narrow/stream/323104-FAST

Track Kick Off and Implementer Support Calls

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 StepsRolesComponents NeededDocumentationValue

A. Find an Endpoint: Access unsecured directory to identify public URL for a different organization (without intermediary)

      1. TODO: Resources exist to help with this and will be populated here.
Distributed workflow directory
  • Directory read access


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

      1. TODO: Client sample code/examples needed; server RI availability TBD; implementations can test against UDAP Test Tool tests  
      2. 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

      1. TODO: Allow and validate writes by trusted clients in Directory RI (Practitioner, PractitionerRole, Restriction)
      2. 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

    1. Prerequisite: other testing participants know Patient A details, which can be shared on this worksheet
    2. Prerequisite: systems agree on a target "fake" Patient A and associated demographics (for example, Alice Newman)
    3. Minimum attributes collected:
      1. 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)
      2. home address
      3. date of birth
      4. email address
      5. mobile number (preferred; if a mobile number is not available, collect an alternative number for the individual)
  1. Scenario StepsRolesComponents NeededDocumentationValue

    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

      1. 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 StepsRolesComponents NeededDocumentationValue

A. Organization A accesses endpoint directory (insert Directory IG link) to identify public URL for Organization B

      1. Organization B’s public endpoint resolves to intermediary, Organization C leveraging Hybrid/Intermediary Exchange IG to service Organization B's FHIR requests
      2. 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)

      1. 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) 

      1. Organization B’s public endpoint resolves to intermediary leveraging Hybrid/Intermediary Exchange IG 
      2. 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)

      1. 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)

      1. Intermediary receives match request and routes to Organization B’s private endpoint
      2. Bonus point: request includes Level 1 IDI
      3. Bonus point: response includes Responder’s System Match Output Quality Score from Identity IG in lieu of locally-computed match confidence
      4. Bonus point: requestor provides insufficient demographics and is returned with an informative error and no results
      5. 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
      6. [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

      1. 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 StepsRolesComponents NeededDocumentationValue

A. Organization A accesses endpoint directory (National Directory Endpoint Query) to identify public URL for Organization B

      1. Organization B's public endpoint resolves to Intermediary, Organization C leveraging National Directory Exchange IG to service Organization B's FHIR requests
      2. 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)

      1. 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)

      1. Organization B's endpoint resolves to intermediary leveraging National Directory Exchange IG
      2. FHIR server answering initial discovery request is going to provide the location of its registration endpoint as publicly accessible URL
      3. Bonus Point: Organization A is using an untrusted, expired, or revoked certificate and Organization B therefore does not allow registration


      4. 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


      5. 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)

      1. Nominal case (Tiered OAuth not yet implemeted): authenticate user with credentials tightly coupled to data holder's system
      2. Validate that the listing obtained from the Directory is in fact from the entity via UDAP Server Metadata IG
      3. 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)
      4. 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

      1. Intermediary (if any) receives request and routes to Organization B's private endpoint
      2. Bonus Point: ID token includes insufficicent demographics or Digital Identifier is unknkown and is returned with an informative error and no results
      3. 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
      4. 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 StepsRolesComponents NeededDocumentationValue

A. Organization A accesses endpoint directory (National Directory Endpoint Query) to identify public URL for Organization B

      1. 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) 

      1. Organization B’s public endpoint resolves to intermediary leveraging National Directory Exchange IG 
      2. 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)

      1. Validating that the listing obtained from the Directory is in fact from the entity via UDAP Server Metadata
      2. 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

      1. Bonus point: requestor provides insufficient demographics and is returned with an informative error and no results
      2. 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)

      1. 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

      1. Success criteria: Organization A obtains health data from Organization B