|
|
00-Pre-scenario-Steps/Pre-scenario-00-01-Directory-Lookup-By-Organization
|
1 |
*** Optional Pre-Scenario Setup Step: Directory Lookup By Organization ***
In some Connectathon track scenarios, there is an optional pre-scenario
step where Organization A accesses an endpoint directory (National
Directory Endpoint Query) to obtain the public URL for Organization B.
This step could require any number of searches on Organization, Endpoint,
or OrganizationAffiliation, until the desired URL is obtained. Use this
test for searching by Organization resources.
Test System Details (in order of appearance):
[Origin 1: Organization A's RESTful client]
[Destination 1: National Directory's RESTful FHIR server] |
JSON |
1 |
FHIR 4.0.1
|
|
|
00-Pre-scenario-Steps/Pre-scenario-00-02-Directory-Lookup-By-Endpoint
|
1 |
*** Optional Pre-Scenario Setup Step: Directory Lookup By Endpoint ***
In some Connectathon track scenarios, there is an optional pre-scenario
step where Organization A accesses an endpoint directory (National
Directory Endpoint Query) to obtain the public URL for Organization B.
This step could require any number of searches on Organization, Endpoint,
or OrganizationAffiliation, until the desired URL is obtained. Use this
test for searching by Endpoint resources.
Test System Details (in order of appearance):
[Origin 1: Organization A's RESTful client]
[Destination 1: National Directory's RESTful FHIR server] |
JSON |
1 |
FHIR 4.0.1
|
|
|
00-Pre-scenario-Steps/Pre-scenario-00-03-Directory-Lookup-By-OrganizationAffiliation
|
1 |
*** Optional Pre-Scenario Setup Step: Directory Lookup By OrganizationAffiliation ***
In some Connectathon track scenarios, there is an optional pre-scenario
step where Organization A accesses an endpoint directory (National
Directory Endpoint Query) to obtain the public URL for Organization B.
This step could require any number of searches on Organization, Endpoint,
or OrganizationAffiliation, until the desired URL is obtained. Use this
test for searching by OrganizationAffiliation resources.
Test System Details (in order of appearance):
[Origin 1: Organization A's RESTful client]
[Destination 1: National Directory's RESTful FHIR server] |
JSON |
1 |
FHIR 4.0.1
|
|
|
01-Scenario-1/Scenario-01-Step-B-D-Patient-Match-No-Security
|
1 |
*** Scenario 01 Step B-D Patient Match No Security ***
Scenario 1, steps B-D: Demonstration of $match, Weighting, and Scoring
Without the Use of UDAP Security.
This test expects as input a valid FHIR Patient resource that conforms
to one of the IDI Patient Profiles in the FAST Identity IG, and which
will generate one match. It may be run with different inputs to check
various weights and scores. For the match score to be deterministic,
the tester at Organization A needs to know a patient at Organization B,
and in the input, only include fields that match that Patient exactly.
Which fields are included will determine the expected score. To test
that a weight test is applied by the server (step C), pass an input that
declares an IDI profile but doesn't meet its invariants, and confirm
the server rejects it somehow. There's no guidance on what that means.
Precondition:
Step A. Organization A creates a FHIR Patient resource that conforms to
one of the IDI Patient Profiles in the FAST Identity IG. Organization
A should generate a FHIR Patient resource that drives the desired
weights and scores.
Test System Details (in order of appearance):
[Origin 1: Organization A's RESTful client]
[Destination 1: Organization B's RESTful FHIR server] |
JSON |
2 |
FHIR 4.0.1
|
|
|
01-Scenario-1/Scenario-01-Step-E-Bonus-Insufficient-Demographics
|
2 |
*** Scenario 01 Step E Bonus Insufficient Demographics ***
Scenario 1, step E: Demonstration of $match, Weighting, and Scoring Without
the Use of UDAP Security: Bonus point: requestor provides
insufficient demographics and is returned with an informative error
and no results.
Test System Details (in order of appearance):
[Origin 1: Organization A's RESTful client]
[Destination 1: Organization B's RESTful FHIR server] |
JSON |
2 |
FHIR 4.0.1
|
|
|
01-Scenario-1/Scenario-01-Step-F-Bonus-RLS-Results
|
2 |
*** Scenario 01 Step F Bonus RLS Results ***
Scenario 1, step F: Demonstration of $match, Weighting, and Scoring Without
the Use of UDAP Security: Bonus point: The match request (against a record
locator service) may have context of multiple organizations (e.g. in a TEFCA
context) so that the fullURL element of each matching patient is relevant
and should be returned.
Test System Details (in order of appearance):
[Origin 1: Organization A's RESTful client]
[Destination 1: Organization B's RESTful FHIR server] |
JSON |
2 |
FHIR 4.0.1
|
|
|
02-01-Scenario-2/Scenario-02-A-01-Step-A-G-UDAP-B2B-and-Patient-Match
|
1 |
*** Scenario 2.a.1 Step A-G UDAP B2B and Patient Match, Organization A is authorized ***
Scenario 2: Organization A has a need for information
held by Organization B. It uses HL7 UDAP Business-to-Business Authorization
to request access and then performs a Patient $match. To "obtain health data"
it simply does a FHIR read on the matched patient. Step H is an optional pre-scenario step,
where Organization A looks up the endpoint for Organization B in the National Directory.
For that, see the separate tests "00 Pre-scenario Steps".
2.a.1: Organization A is authorized; does Patient Match.
Test System Details (in order of appearance):
[Origin 1: Organization A's RESTful client]
[Destination 1: Organization B's OAuth Resource Server (i.e. where UDAP metadata is available at <base>/.well-known/udap, and a RESTful FHIR Server at <base> if appropriate)]
[Destination 2: Organization B's UDAP OAuth Authorization Server]
NOTE: This TestScript requires an external client. It will not function correctly if Touchstone is chosen as the client. |
JSON |
8 |
FHIR 4.0.1
|
|
|
02-01-Scenario-2/Scenario-02-A-02-Step-A-G-UDAP-B2B-and-Patient-Read
|
1 |
*** Scenario 2.a.2 Step A-G UDAP B2B and Patient Read, Organization A is authorized ***
Scenario 2: Organization A has a need for information
held by Organization B. It uses HL7 UDAP Business-to-Business Authorization
to request access and then to "obtain health data" it simply does a FHIR read
on a known patient (this variant skips the $match). Step H is an optional pre-scenario step,
where Organization A looks up the endpoint for Organization B in the National Directory.
For that, see the separate tests "00 Pre-scenario Steps".
2.a.2: Organization A is authorized; does Patient Read.
Test System Details (in order of appearance):
[Origin 1: Organization A's RESTful client]
[Destination 1: Organization B's OAuth Resource Server (i.e. where UDAP metadata is available at <base>/.well-known/udap, and a RESTful FHIR Server at <base> if appropriate)]
[Destination 2: Organization B's UDAP OAuth Authorization Server]
NOTE: This TestScript requires an external client. It will not function correctly if Touchstone is chosen as the client. |
JSON |
5 |
FHIR 4.0.1
|
|
|
02-01-Scenario-2/Scenario-02-B-01-UDAP-B2B-Error-Not-Auth-For-B2B
|
1 |
*** Scenario 2.b UDAP B2B and Patient Match, Organization D not authorized for B2B ***
Scenario 2: Organization D has a need for information
held by Organization B. It uses HL7 UDAP Business-to-Business Authorization
to request access and then performs a Patient $match.
2.b: negative test: Try same process with a different
Organization who exists, but does not have authorization.
2.b.1 The Organization is not authorized at this server to
register for B2B.
Test System Details (in order of appearance):
[Origin 1: Organization D's RESTful client]
[Destination 1: Organization B's OAuth Resource Server (i.e. where UDAP metadata is available at <base>/.well-known/udap, and a RESTful FHIR Server at <base> if appropriate)]
[Destination 2: Organization B's UDAP OAuth Authorization Server]
NOTE: This TestScript requires an external client. It will not function correctly if Touchstone is chosen as the client. |
JSON |
2 |
FHIR 4.0.1
|
|
|
02-01-Scenario-2/Scenario-02-B-02-UDAP-B2B-Error-Not-Auth-For-Request
|
1 |
*** Scenario 2.b UDAP B2B and Patient Match, Organization E not authorized for request ***
Scenario 2: Organization E has a need for information
held by Organization B. It uses HL7 UDAP Business-to-Business Authorization
to request access and then performs a Patient $match.
2.b: negative test: Try same process with a different
Organization who exists, but does not have authorization.
2.b.2 The Organization is not authorized at this server to make
this request.
Test System Details (in order of appearance):
[Origin 1: Organization E's RESTful client]
[Destination 1: Organization B's OAuth Resource Server (i.e. where UDAP metadata is available at <base>/.well-known/udap, and a RESTful FHIR Server at <base> if appropriate)]
[Destination 2: Organization B's UDAP OAuth Authorization Server]
NOTE: This TestScript requires an external client. It will not function correctly if Touchstone is chosen as the client. |
JSON |
3 |
FHIR 4.0.1
|