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)

Track Lead Email(s)

jeffbrown@mitre.org; rdieterle@enablecare.us; awatson@mitre.org; smahoney@mitre.org, ashankland@mitre.org

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

Call for participants

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

Zulip stream

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

Track Implementers Connection Call

Weekly Friday meetings leading up to the Connectathon starting June 17, 2022 11am-12pm ET

HL7 FAST Infrastructure Track Kick-off v8.pdf

HL7 FAST Infrastructure Track Kick-off Recording

HL7 FAST Implementer Connection Call Recording_071522 and Presentation 

HL7 FAST Implementer Connection Call Recording_070822

HL7 FAST Implementer Connection Call Recording_070122

HL7 FAST Implementer Connection Call Recording_062422


Zoom Meeting: https://hl7-org.zoom.us/j/97529639226?pwd=MXJMUHRINkhUWXd6MXlPaW1OWnlvZz09

Meeting ID: 975 2963 9226

Passcode: 367245

Dial by your location

        +1 301 715 8592 US (Washington DC)

        +1 312 626 6799 US (Chicago)

        +1 646 558 8656 US (New York)

        +1 253 215 8782 US (Tacoma)

        +1 346 248 7799 US (Houston)

        +1 669 900 9128 US (San Jose)

Testing Scenario:

Actors:

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 authentication + policy logic for writes and sensitive data access

Organization A - UDAP FHIR client (Requestor)

  • Client Requesting FHIR data 
  • Certificate

Organization B - FHIR server B (Responder)

  • UDAP Server Metadata
  • 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 Services (one or more of the following roles)

  • Remote (online) Identity verification
  • Support of an in-person Identity verification process 
  • Authenticate a user and provide an ID Token to the Responder as a trusted OIDC IdP in UDAP Tiered OAuth


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

    1. (Fnd 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.
    2. (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
    3. (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


2. Patient A visits Organization B for an appointment; Organization B 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. [scenario may define specific ID proofing levels for A/B, or one of the orgs proofs according to the IG and the other doesn’t; this can be indicated in the authorization extension object or user profile data; layer on more specifics once Identity IG offers attribute validation grammar]
    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, and consider that there are free services to create one since having one facilitates matching and credential management; if a mobile number is not available, collect an alternative number for the individual)
    4. Verify Patient A's identity at a target level of assurance 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 
    5. Demographics (and later: optional validation status) are ready to be used in a $match request as per UDAP Security, Identity IG
    6. Bonus point: create a Digital Identifier with associated OpenID Connect Credential and authenticator for Patient A as per Digital Identity within Identity IG
    7. Bonus point: capture verification status at attribute, encounter, or record level (not yet specified in Identity IG; prior work exists for encounter-level use in SMART Health Cards).


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 

    1. 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
    2. 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)
    3. 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
    4. 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?)
    5. 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 demographics with verification status in $match request and responder's system appropriately scores match input and uses as input to response policy engine
      6. [What other aspects of ID/matching IG should be tested?]
    6. Organization B responds with match(es) & associated patient ID(s) and intermediary routes response back to Organization A
    7. 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
    8. Success criteria: Organization A obtains health data from Organization B

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)

    1. 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
    2. 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. Directory RI will populate and secure a sensitive endpoint (Practitioner, PractitionerRole, Restriction)
    3. 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
    4. 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. Validating that the listing obtained from the Directory is in fact from the entity via UDAP Server Metadata IG
      2. 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)
      3. 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
    5. Organization B returns token response and intermediary routes back to Organization A
    6. Organization A requests health data from Organization B's endpoint
      1. Intermediary 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: Requestor provides demographics with verification status in ID token and responder's system appropriately scores match input and uses as input to response policy engine
      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
    7. Success Criteria: Organization A obtains health data from Organization B
    8. 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
    9. Bonus Point: OIDC user profile includes account-level identity and/or authentication level of assurance
    10. Bonus Point: OIDC user profile includes verified demographics as in  Identity IG


5. Test sharing demographic attributes within an authorization extension object in UDAP Security's JWT-based authentication B2B (and as per Carequality FHIR IG) in a Patient Access workflow not requiring patient credentials at the responder’s organization

    1. 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. 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)
    3. 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
    4. 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
    5. 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
    6. 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
    7. Organization A requests health data for the patient from Organization B public endpoint
    8. Intermediary receives request and routes to Organization B private endpoint
      1. Success criteria: Organization A obtains health data from Organization B



Track Kick Off Presentation (June 17th)

Track Report Out (July 22nd)