FHIR
Page tree
Skip to end of metadata
Go to start of metadata


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)

Jeff Brown , Robert Dieterle , Abigail Watson , Sean Mahoney, Alex Shankland

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 Kick Off Call

Next Implementer Prep Call: Tuesday, Sept 13th, 4-5pm ET

Join Zoom Meeting

https://hl7-org.zoom.us/j/95095913028?pwd=d3ZsY09sbkh1Ni82YXR5V3NxRm9XUT09

Meeting ID: 950 9591 3028

Passcode: 395010

Dial by your location

+1 312 626 6799 US (Chicago); +1 646 558 8656 US (New York); +1 646 931 3860 US; +1 301 715 8592 US (Washington DC); +1 309 205 3325 US; +1 564 217 2000 US; +1 669 444 9171 US; +1 669 900 9128 US (San Jose); +1 719 359 4580 US; +1 253 215 8782 US (Tacoma); +1 346 248 7799 US (Houston);+1 386 347 5053 US

FAST Infrastructure breakout sessions - Saturday, September 17th:

  1. Dynamic Registration – B2B/B2C and B2B Auth – 1-2pm ET (Room: Homeland)
  2. Reusable Digital Identities (B2C) – 3-4pm ET (Room: Homeland)
  3. Matching Options Beyond Patient $match (B2B) – 4-5pm ET (Room: Fells Point)

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 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 + 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 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

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

    		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 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?]
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

      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

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

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

      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 are scored by responder's system and used along with CLient's credentials as input to data holder's 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
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










Track Kick Off Presentation (September 13)

2 Comments

  1. Cait Ryan

    For those interested in using the Touchstone Proxy feature, please watch the following videos:

    VIDEO 1: FHIR Testing - Using Touchstone's Peer-to-Peer/Proxy Features to Capture and Test FHIR Exchanges (https://youtu.be/08QofGL2gZE)Video 2: FHIR Test Server Setup for Peer-to-Peer/Proxy Testing in Touchstone & Connectathon Manager (ConMan) (https://www.youtube.com/watch?v=Xt9Vre-YsbU)

    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.

  2. 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):