Call for participants | Providers, EHR Vendors, Payers, Intermediaries (e.g., HIEs, Clearinghouses, etc.) |
| 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 - (Fnd 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.
- (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
- (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 - Prerequisite: other testing participants know Patient A details, which can be shared on this worksheet
- [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]
- 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, 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)
- Verify Patient A's identity at a target level of assurance 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
- Demographics (and later: optional validation status) are ready to be used in a $match request as per UDAP Security, Identity IG
- Bonus point: create a Digital Identifier with associated OpenID Connect Credential and authenticator for Patient A as per Digital Identity within Identity IG
- 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 - 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
- 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 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
- 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 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 B responds with match(es) & associated patient ID(s) and intermediary routes response back to Organization A
- 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
- 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) - 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
- 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)
- Directory RI will populate and secure a sensitive endpoint (Practitioner, PractitionerRole, Restriction)
- 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, 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 B returns token response and intermediary routes back to Organization A
- Organization A requests health data from Organization B's endpoint
- Intermediary 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: 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
- Bonus Point: Organization B performs other out of band interaction with Patient A that enables use of their Digital Identity to access health data
- Success Criteria: Organization A obtains health data from Organization B
- 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
- Bonus Point: OIDC user profile includes account-level identity and/or authentication level of assurance
- 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 - 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
- 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)
- 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
- 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
- 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
- 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
- Organization A requests health data for the patient from Organization B public endpoint
- Intermediary receives request and routes to Organization B private endpoint
- Success criteria: Organization A obtains health data from Organization B
|
