davinci_pas_test_kit 0.13.1 → 0.13.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/lib/davinci_pas_test_kit/client_suite.rb +38 -1
- data/lib/davinci_pas_test_kit/generated/v2.0.1/server_suite.rb +40 -1
- data/lib/davinci_pas_test_kit/generator/templates/suite.rb.erb +40 -1
- data/lib/davinci_pas_test_kit/metadata.rb +5 -5
- data/lib/davinci_pas_test_kit/version.rb +2 -2
- metadata +2 -4
- data/lib/davinci_pas_test_kit/docs/client_suite_description_v201.md +0 -444
- data/lib/davinci_pas_test_kit/docs/server_suite_description_v201.md +0 -168
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA256:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: eab60793f7ecc9d8f6e629c5c383a1c862944805eea21772dafcbcc45ecd1915
|
|
4
|
+
data.tar.gz: c657b115fa076a0ed2ca74181725f55591f6814714f0a917d5be557978708790
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: c35c4998d5dae26f61454695424235bd948ebae145a09f39557b97c31e487dea46b71b7afe0e6fdb65902ae80eebfcbc682606618516fea8ff929aaccd80a53b
|
|
7
|
+
data.tar.gz: 23f797fc60bcb69395a631d2b05e6d942b9c1179528aa331319c43a5a3e6e81084c96cd1b54a0e92fc562f9f66e843f956d2a805296126b44ac177807cb005f9
|
|
@@ -22,7 +22,44 @@ module DaVinciPASTestKit
|
|
|
22
22
|
class ClientSuite < Inferno::TestSuite
|
|
23
23
|
id :davinci_pas_client_suite_v201
|
|
24
24
|
title 'Da Vinci PAS Client Suite v2.0.1'
|
|
25
|
-
description
|
|
25
|
+
description %(
|
|
26
|
+
The Da Vinci PAS Test Kit Client Suite validates the conformance of client
|
|
27
|
+
systems to the STU 2 version of the HL7® FHIR®
|
|
28
|
+
[Da Vinci Prior Authorization Support Implementation Guide](https://hl7.org/fhir/us/davinci-pas/STU2/).
|
|
29
|
+
|
|
30
|
+
These tests are a **DRAFT** intended to allow PAS client implementers to perform
|
|
31
|
+
preliminary checks of their clients against PAS IG requirements and [provide
|
|
32
|
+
feedback](https://github.com/inferno-framework/davinci-pas-test-kit/issues)
|
|
33
|
+
on the tests. Future versions of these tests may validate other
|
|
34
|
+
requirements and may change the test validation logic.
|
|
35
|
+
|
|
36
|
+
The best place to get started is the [Client Testing
|
|
37
|
+
Walkthrough](https://github.com/inferno-framework/davinci-pas-test-kit/wiki/Client-Walkthrough),
|
|
38
|
+
which provides a step-by-step guide for running the tests against a client and provides
|
|
39
|
+
an example client implemented in Postman. Visit the [Client Testing
|
|
40
|
+
Details](https://github.com/inferno-framework/davinci-pas-test-kit/wiki/Client-Details)
|
|
41
|
+
documentation for information about technical implementation and known limitations of these tests.
|
|
42
|
+
|
|
43
|
+
In this test suite, Inferno simulates a PAS server for the client under test to
|
|
44
|
+
interact with. The client will be expected to initiate requests to the server
|
|
45
|
+
and demonstrate its ability to react to the returned responses. Over the course
|
|
46
|
+
of these interactions, Inferno will seek to observe conformant handling of PAS
|
|
47
|
+
requirements, including:
|
|
48
|
+
- The ability of the client to initiate a prior authorization submission and react to
|
|
49
|
+
- The approval of the request
|
|
50
|
+
- The denial of the request
|
|
51
|
+
- The pending of the request and a subsequent notification that a final decision was made
|
|
52
|
+
- The ability of the client to provide data covering the full scope of required by PAS, including
|
|
53
|
+
- The ability to send prior auth requests and inquiries with all PAS
|
|
54
|
+
profiles and all must support elements on those profiles
|
|
55
|
+
- The ability to handle responses that contain all PAS profiles and all must support elements on those
|
|
56
|
+
profiles (not included in the current version of these tests)
|
|
57
|
+
|
|
58
|
+
All requests and responses will be checked for conformance to the PAS
|
|
59
|
+
IG requirements individually and used in aggregate to determine whether
|
|
60
|
+
required features and functionality are present. HL7® FHIR® resources are
|
|
61
|
+
validated with the Java validator using `tx.fhir.org` as the terminology server.
|
|
62
|
+
)
|
|
26
63
|
|
|
27
64
|
links [
|
|
28
65
|
{
|
|
@@ -11,7 +11,46 @@ module DaVinciPASTestKit
|
|
|
11
11
|
class ServerSuite < Inferno::TestSuite
|
|
12
12
|
id :davinci_pas_server_suite_v201
|
|
13
13
|
title 'Da Vinci PAS Server Suite v2.0.1'
|
|
14
|
-
description
|
|
14
|
+
description %(
|
|
15
|
+
The Da Vinci PAS Server Suite validates the conformance of server systems
|
|
16
|
+
to the STU 2 version of the HL7® FHIR®
|
|
17
|
+
[Da Vinci Prior Authorization Support Implementation Guide](https://hl7.org/fhir/us/davinci-pas/STU2/).
|
|
18
|
+
|
|
19
|
+
These tests are a **DRAFT** intended to allow PAS server implementers to perform
|
|
20
|
+
preliminary checks of their servers against PAS IG requirements and [provide
|
|
21
|
+
feedback](https://github.com/inferno-framework/davinci-pas-test-kit/issues)
|
|
22
|
+
on the tests. Future versions of these tests may validate other
|
|
23
|
+
requirements and may change the test validation logic.
|
|
24
|
+
|
|
25
|
+
The best place to get started is the [Server Testing
|
|
26
|
+
Walkthrough](https://github.com/inferno-framework/davinci-pas-test-kit/wiki/Server-Walkthrough),
|
|
27
|
+
which provides a step-by-step guide for running the tests against a client and provides
|
|
28
|
+
an example client implemented in Postman. Visit the [Server Testing
|
|
29
|
+
Details](https://github.com/inferno-framework/davinci-pas-test-kit/wiki/Server-Details)
|
|
30
|
+
documentation for information about technical implementation and known limitations of these tests.
|
|
31
|
+
|
|
32
|
+
Inferno will simulate a client and make a series of prior authorization requests to the
|
|
33
|
+
server under test. Over the course of these requests, Inferno will seek to observe
|
|
34
|
+
conformant handling of PAS requirements, including
|
|
35
|
+
- The ability of the server to use PAS API interactions to communicate
|
|
36
|
+
- Approval of a prior authorization request
|
|
37
|
+
- Denial of a prior authorization request
|
|
38
|
+
- Pending of a prior authorization request and a subsequent final decision
|
|
39
|
+
- Inability to process a prior authorization request
|
|
40
|
+
- The ability of the server to handle the full scope of data required by PAS, including
|
|
41
|
+
- Ability to process prior auth requests and inquiries with all PAS profiles and all must support elements on those profiles
|
|
42
|
+
- Ability to return responses that demonstrate the use of all PAS profiles and all must support elements on those profiles
|
|
43
|
+
|
|
44
|
+
Because the business logic that determines decisions and the elements populated in responses
|
|
45
|
+
Is outside of the PAS specification and will vary between implementers, testers
|
|
46
|
+
are required to provide the requests that Inferno will make to the server.
|
|
47
|
+
|
|
48
|
+
All requests and responses will be checked for conformance to the PAS
|
|
49
|
+
IG requirements individually and used in aggregate to determine whether
|
|
50
|
+
required features and functionality are present. HL7® FHIR® resources are
|
|
51
|
+
validated with the Java validator using `tx.fhir.org` as the terminology server.
|
|
52
|
+
|
|
53
|
+
%)
|
|
15
54
|
|
|
16
55
|
links [
|
|
17
56
|
{
|
|
@@ -8,7 +8,46 @@ module DaVinciPASTestKit
|
|
|
8
8
|
class <%= class_name %> < Inferno::TestSuite
|
|
9
9
|
id :<%= suite_id %>
|
|
10
10
|
title '<%= title %>'
|
|
11
|
-
description
|
|
11
|
+
description %(
|
|
12
|
+
The Da Vinci PAS Server Suite validates the conformance of server systems
|
|
13
|
+
to the STU 2 version of the HL7® FHIR®
|
|
14
|
+
[Da Vinci Prior Authorization Support Implementation Guide](https://hl7.org/fhir/us/davinci-pas/STU2/).
|
|
15
|
+
|
|
16
|
+
These tests are a **DRAFT** intended to allow PAS server implementers to perform
|
|
17
|
+
preliminary checks of their servers against PAS IG requirements and [provide
|
|
18
|
+
feedback](https://github.com/inferno-framework/davinci-pas-test-kit/issues)
|
|
19
|
+
on the tests. Future versions of these tests may validate other
|
|
20
|
+
requirements and may change the test validation logic.
|
|
21
|
+
|
|
22
|
+
The best place to get started is the [Server Testing
|
|
23
|
+
Walkthrough](https://github.com/inferno-framework/davinci-pas-test-kit/wiki/Server-Walkthrough),
|
|
24
|
+
which provides a step-by-step guide for running the tests against a client and provides
|
|
25
|
+
an example client implemented in Postman. Visit the [Server Testing
|
|
26
|
+
Details](https://github.com/inferno-framework/davinci-pas-test-kit/wiki/Server-Details)
|
|
27
|
+
documentation for information about technical implementation and known limitations of these tests.
|
|
28
|
+
|
|
29
|
+
Inferno will simulate a client and make a series of prior authorization requests to the
|
|
30
|
+
server under test. Over the course of these requests, Inferno will seek to observe
|
|
31
|
+
conformant handling of PAS requirements, including
|
|
32
|
+
- The ability of the server to use PAS API interactions to communicate
|
|
33
|
+
- Approval of a prior authorization request
|
|
34
|
+
- Denial of a prior authorization request
|
|
35
|
+
- Pending of a prior authorization request and a subsequent final decision
|
|
36
|
+
- Inability to process a prior authorization request
|
|
37
|
+
- The ability of the server to handle the full scope of data required by PAS, including
|
|
38
|
+
- Ability to process prior auth requests and inquiries with all PAS profiles and all must support elements on those profiles
|
|
39
|
+
- Ability to return responses that demonstrate the use of all PAS profiles and all must support elements on those profiles
|
|
40
|
+
|
|
41
|
+
Because the business logic that determines decisions and the elements populated in responses
|
|
42
|
+
Is outside of the PAS specification and will vary between implementers, testers
|
|
43
|
+
are required to provide the requests that Inferno will make to the server.
|
|
44
|
+
|
|
45
|
+
All requests and responses will be checked for conformance to the PAS
|
|
46
|
+
IG requirements individually and used in aggregate to determine whether
|
|
47
|
+
required features and functionality are present. HL7® FHIR® resources are
|
|
48
|
+
validated with the Java validator using `tx.fhir.org` as the terminology server.
|
|
49
|
+
|
|
50
|
+
%)
|
|
12
51
|
|
|
13
52
|
links [
|
|
14
53
|
{
|
|
@@ -12,6 +12,10 @@ module DaVinciPASTestKit
|
|
|
12
12
|
|
|
13
13
|
<!-- break -->
|
|
14
14
|
|
|
15
|
+
Please visit the [Da Vinci PAS Test Kit documentation
|
|
16
|
+
site](https://github.com/inferno-framework/davinci-pas-test-kit/wiki/) for
|
|
17
|
+
detailed information on how to use and maintain this test kit.
|
|
18
|
+
|
|
15
19
|
To validate the behavior of a system Inferno will act as the partner to the
|
|
16
20
|
system under test:
|
|
17
21
|
- **When testing a client**: Inferno will act as a server, awaiting requests
|
|
@@ -58,16 +62,12 @@ module DaVinciPASTestKit
|
|
|
58
62
|
e.g., the requirement that clinicians can update details of the prior authorization
|
|
59
63
|
request before submitting them
|
|
60
64
|
|
|
61
|
-
For additional details on these and other areas where the tests may not align with
|
|
62
|
-
the IGs requirements, see documentation in the test kit source code ([client](https://github.com/inferno-framework/davinci-pas-test-kit/blob/main/lib/davinci_pas_test_kit/docs/client_suite_description_v201.md#testing-limitations), [server](https://github.com/inferno-framework/davinci-pas-test-kit/blob/main/lib/davinci_pas_test_kit/docs/server_suite_description_v201.md#testing-limitations)), and [this requirements analysis
|
|
63
|
-
spreadsheet](https://github.com/inferno-framework/davinci-pas-test-kit/blob/main/lib/davinci_pas_test_kit/docs/PAS%20Requirements%20Interpretation.xlsx).
|
|
64
|
-
|
|
65
65
|
### Known IG Issues
|
|
66
66
|
|
|
67
67
|
Through testing with this test kit, issues have been identified in the version of the PAS
|
|
68
68
|
specification that this test kit tests against which cause false failures. The full list
|
|
69
69
|
of known issues can be found on the [repository's issues page with the 'source ig issue'
|
|
70
|
-
|
|
70
|
+
label](https://github.com/inferno-framework/davinci-pas-test-kit/labels/source%20ig%20issue).
|
|
71
71
|
|
|
72
72
|
## Reporting Issues
|
|
73
73
|
|
metadata
CHANGED
|
@@ -1,14 +1,14 @@
|
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
|
2
2
|
name: davinci_pas_test_kit
|
|
3
3
|
version: !ruby/object:Gem::Version
|
|
4
|
-
version: 0.13.
|
|
4
|
+
version: 0.13.2
|
|
5
5
|
platform: ruby
|
|
6
6
|
authors:
|
|
7
7
|
- Inferno Team
|
|
8
8
|
autorequire:
|
|
9
9
|
bindir: bin
|
|
10
10
|
cert_chain: []
|
|
11
|
-
date: 2025-05-
|
|
11
|
+
date: 2025-05-30 00:00:00.000000000 Z
|
|
12
12
|
dependencies:
|
|
13
13
|
- !ruby/object:Gem::Dependency
|
|
14
14
|
name: inferno_core
|
|
@@ -181,9 +181,7 @@ files:
|
|
|
181
181
|
- lib/davinci_pas_test_kit/custom_groups/v2.0.1/pas_server_subscription_setup.rb
|
|
182
182
|
- lib/davinci_pas_test_kit/descriptions.rb
|
|
183
183
|
- lib/davinci_pas_test_kit/docs/PAS Requirements Interpretation.xlsx
|
|
184
|
-
- lib/davinci_pas_test_kit/docs/client_suite_description_v201.md
|
|
185
184
|
- lib/davinci_pas_test_kit/docs/demo/PAS Client Suite Demonstration.postman_collection.json
|
|
186
|
-
- lib/davinci_pas_test_kit/docs/server_suite_description_v201.md
|
|
187
185
|
- lib/davinci_pas_test_kit/endpoints/claim_endpoint.rb
|
|
188
186
|
- lib/davinci_pas_test_kit/endpoints/subscription_create_endpoint.rb
|
|
189
187
|
- lib/davinci_pas_test_kit/endpoints/subscription_status_endpoint.rb
|
|
@@ -1,444 +0,0 @@
|
|
|
1
|
-
The Da Vinci PAS Test Kit Client Suite validates the conformance of client
|
|
2
|
-
systems to the STU 2 version of the HL7® FHIR®
|
|
3
|
-
[Da Vinci Prior Authorization Support Implementation Guide](https://hl7.org/fhir/us/davinci-pas/STU2/).
|
|
4
|
-
|
|
5
|
-
## Scope
|
|
6
|
-
|
|
7
|
-
These tests are a **DRAFT** intended to allow PAS client implementers to perform
|
|
8
|
-
preliminary checks of their clients against PAS IG requirements and [provide
|
|
9
|
-
feedback](https://github.com/inferno-framework/davinci-pas-test-kit/issues)
|
|
10
|
-
on the tests. Future versions of these tests may validate other
|
|
11
|
-
requirements and may change the test validation logic.
|
|
12
|
-
|
|
13
|
-
## Test Methodology
|
|
14
|
-
|
|
15
|
-
Inferno will simulate a PAS server for the client under test to interact with. The client
|
|
16
|
-
will be expected to initiate requests to the server and demonstrate its ability to react
|
|
17
|
-
to the returned responses. Over the course of these interactions,
|
|
18
|
-
Inferno will seek to observe conformant handling of PAS requirements, including
|
|
19
|
-
- The ability of the client to initiate a prior authorization submission and react to
|
|
20
|
-
- The approval of the request
|
|
21
|
-
- The denial of the request
|
|
22
|
-
- The pending of the request and a subsequent notification that a final decision was made
|
|
23
|
-
- The ability of the client to provide data covering the full scope of required by PAS, including
|
|
24
|
-
- The ability to send prior auth requests and inquiries with all PAS profiles and all must support elements on
|
|
25
|
-
those profiles
|
|
26
|
-
- The ability to handle responses that contain all PAS profiles and all must support elements on those
|
|
27
|
-
profiles (not included in the current version of these tests)
|
|
28
|
-
|
|
29
|
-
All requests and responses will be checked for conformance to the PAS
|
|
30
|
-
IG requirements individually and used in aggregate to determine whether
|
|
31
|
-
required features and functionality are present. HL7® FHIR® resources are
|
|
32
|
-
validated with the Java validator using `tx.fhir.org` as the terminology server.
|
|
33
|
-
|
|
34
|
-
### Responses
|
|
35
|
-
|
|
36
|
-
Inferno contains basic logic to generate approval, denial, and pended responses, along with a
|
|
37
|
-
notification that a final decision was made, as a part of the above workflows.
|
|
38
|
-
These responses are based on examples available in the PAS Implementation Guide
|
|
39
|
-
and are conformant, but may not meet the needs of actual implementations. Thus,
|
|
40
|
-
testers may provide Inferno with specific responses for Inferno to echo. If responses
|
|
41
|
-
are provided, Inferno will check them for conformance to ensure that they demonstrate
|
|
42
|
-
a fully conformant exchange.
|
|
43
|
-
|
|
44
|
-
### Authentication
|
|
45
|
-
|
|
46
|
-
The [Privacy and Security section](https://hl7.org/fhir/us/davinci-pas/STU2/privacy.html) of the PAS
|
|
47
|
-
Implementation Guide states that payers must "require that the provider system authenticates"
|
|
48
|
-
itself when making PAS requests against the payer system. However, the specific method of authentication
|
|
49
|
-
is left to the Da Vinci HRex IG, which [provides recommendations and potential
|
|
50
|
-
approaches](https://hl7.org/fhir/us/davinci-hrex/STU1/security.html#exchange-security) for
|
|
51
|
-
authentication, but does not require a specific one to be used. Inferno requires some
|
|
52
|
-
authentication approach to be used in order for it to be able to identify which incoming
|
|
53
|
-
requests are from the client under test.
|
|
54
|
-
|
|
55
|
-
Inferno's simulated payer server includes a simulation of two standard authentication approaches:
|
|
56
|
-
- SMART Backend Services
|
|
57
|
-
- UDAP B2B client credentials flow, including dynamic registration
|
|
58
|
-
|
|
59
|
-
Clients under test can register with the authorization server and request tokens for use
|
|
60
|
-
when making PAS requests. In this case, Inferno will verify that the client's interactions with
|
|
61
|
-
the simulated authorization server are conformant and that the provided tokens are used.
|
|
62
|
-
|
|
63
|
-
If the client under test does not support either of these standards-based methods of authentication, the tester
|
|
64
|
-
may instead attest to other authentication capabilities. In this case, the client will authenticate
|
|
65
|
-
by sending requests to dedicated PAS endpoints created by Inferno for use during the testing session.
|
|
66
|
-
To reduce configuration burden, the dedicated endpoints can be reused in subsequent sessions.
|
|
67
|
-
|
|
68
|
-
## Running the Tests
|
|
69
|
-
|
|
70
|
-
### Quick Start
|
|
71
|
-
|
|
72
|
-
To execute a simple set of tests with minimal setup and input, perform an approval workflow using
|
|
73
|
-
inferno-generated responses and dedicated session-specific endpoints with the following steps:
|
|
74
|
-
|
|
75
|
-
1. Create a Da Vinci PAS Client Suite v2.0.1 session using the "Other Authentication" option
|
|
76
|
-
for the Client Security Type.
|
|
77
|
-
1. Select the "Client Registration" group from the list at the left and and click
|
|
78
|
-
the "RUN TESTS" button in the upper right.
|
|
79
|
-
1. Optionally provide a value for the **Session-specific URL path extension** input to
|
|
80
|
-
specify the extra path for the dedicated session endpoint or leave blank to let
|
|
81
|
-
Inferno generate a value for you. Then click the "SUBMIT" button at the bottom right.
|
|
82
|
-
1. Attest to an alternate authentication approach in the wait dialog that appears and
|
|
83
|
-
then configure your client to connect to the Inferno FHIR server subsequently displayed
|
|
84
|
-
and click the link continue.
|
|
85
|
-
1. Select the "Approval Workflow" group from the list at the left and click
|
|
86
|
-
the "RUN TESTS" button in the upper right.
|
|
87
|
-
1. Click the "SUBMIT" button at the bottom right of the input dialog that appears.
|
|
88
|
-
1. Submit a PAS prior authorization request to the endpoint shown in the wait
|
|
89
|
-
dialog that appears.
|
|
90
|
-
1. When another wait dialog appears, check your system to see whether Inferno's response
|
|
91
|
-
was interpreted as an approval or not and click the appropriate link in the dialog.
|
|
92
|
-
1. Review the results including any errors or warnings found when checking the conformance
|
|
93
|
-
of the request or the generated response.
|
|
94
|
-
|
|
95
|
-
Group "Denial Workflow" can be run in the same manner. To run the "Pended Workflow" group,
|
|
96
|
-
first run the "Subscription Setup" group, during which the client system will submit a
|
|
97
|
-
Subscription so that Inferno knows how and where to send a notification that a decision has
|
|
98
|
-
been rendered on a pended prior authorization request. Then proceed to execute the
|
|
99
|
-
"Pended Workflow" group and follow the instructions in the dialogs that appear.
|
|
100
|
-
|
|
101
|
-
### Postman-based Demonstration
|
|
102
|
-
|
|
103
|
-
If you do not have a PAS client but would like to try the tests out, you can use
|
|
104
|
-
[this postman collection](https://github.com/inferno-framework/davinci-pas-test-kit/blob/main/lib/davinci_pas_test_kit/docs/demo/PAS%20Client%20Suite%20Demonstration.postman_collection.json)
|
|
105
|
-
to make requests against Inferno and see the mocked responses provided by Inferno. To use, load
|
|
106
|
-
the collection into the [Postman app](https://www.postman.com/downloads/) and follow these steps:
|
|
107
|
-
|
|
108
|
-
1. Start a Da Vinci PAS Client Suite v2.0.1 session from the [PAS Test Kit page on
|
|
109
|
-
inferno.healthit.gov](https://inferno.healthit.gov/test-kits/davinci-pas/),
|
|
110
|
-
choosing the "Other Authentication" option for the Client Security Type.
|
|
111
|
-
2. Click the *Run All Tests* button in the upper right hand corner of the suite.
|
|
112
|
-
3. Client Registration
|
|
113
|
-
- In the **Session-specific URL path extension** input, put a short alpha string, such as `demo`
|
|
114
|
-
- In Postman, select the *PAS Client Suite Demonstration* Collection in postman and go to the "Variables" tab
|
|
115
|
-
(see the collection's Overview tab for more details on what the variables control).
|
|
116
|
-
- In the current value for the **session_url_path** variable, put the same value as in the
|
|
117
|
-
**Session-specific URL path extension** input, surrounded by `/`, e.g., `/demo/` and
|
|
118
|
-
save the collection.
|
|
119
|
-
- Back in Inferno, click the "SUBMIT" button and click the links to continue the tests
|
|
120
|
-
in the next two wait dialogs until a **Subscription Creation Test** wait dialog appears.
|
|
121
|
-
1. In Postman, select the *Create Subscription Request* in the *Subscription Setup* folder
|
|
122
|
-
and click the "Send" button in the upper right.
|
|
123
|
-
1. Back in Inferno, the wait dialog should disappear and a new **Approval Workflow Test** wait
|
|
124
|
-
dialog will appear.
|
|
125
|
-
1. In Postman, select the *Prior Auth Request For Approval* in the *Approval Workflow* folder
|
|
126
|
-
and click the "Send" button in the upper right.
|
|
127
|
-
1. Back in Inferno, the wait dialog should disappear and a new attestation wait dialog will
|
|
128
|
-
appear asking to confirm the system's interpretation of the "Approved" response. Check that
|
|
129
|
-
the response from the last step in Postman contains the string "Certified in total" and respond
|
|
130
|
-
to the attestation. The wait dialog should disappear and a new **Denial Workflow Test** wait
|
|
131
|
-
dialog will appear.
|
|
132
|
-
1. In Postman, select the *Prior Auth Request For Denial* in the *Denial Workflow* folder
|
|
133
|
-
and click the "Send" button in the upper right.
|
|
134
|
-
1. Back in Inferno, the wait dialog should disappear and a new attestation wait dialog will
|
|
135
|
-
appear asking to confirm the system's interpretation of the "Denied" response. Check that
|
|
136
|
-
the response from the last step in Postman contains the string "Not Certified" and respond
|
|
137
|
-
to the attestation. The wait dialog should disappear and a new **Pended Workflow Test** wait
|
|
138
|
-
dialog will appear.
|
|
139
|
-
1. In Postman, select the *Prior Auth Request For Pended* entry under the *Pended Workflow* folder in the
|
|
140
|
-
and click the "Send" button in the upper right.
|
|
141
|
-
1. Search in the response returned to Postman for the string "Pending" which indicates the prior
|
|
142
|
-
auth request was pended and a final decision will be made later. You'll use this information in
|
|
143
|
-
a later attestation.
|
|
144
|
-
1. Meanwhile, Inferno sent a notification indicating that a final decision was made (5-10 seconds
|
|
145
|
-
after the prior auth request). If interested in seeing the notification message, it can be found
|
|
146
|
-
on the [notifications
|
|
147
|
-
page](https://subscriptions.argo.run/subscriptions/notifications-received?store=r4) for the
|
|
148
|
-
[Argonaut Subscriptions Reference Implementation](https://subscriptions.argo.run/), which
|
|
149
|
-
hosts a notification endpoint that is used to receive Subscription notifications for this demo.
|
|
150
|
-
Note that when looking for recent notifications, **Received** timestamps are in UTC which is
|
|
151
|
-
5 hours ahead of Eastern Standard Time (4 hours ahead of Eastern Daylight Time).
|
|
152
|
-
1. In Postman, select the *Prior Auth Inquiry for Pended* entry under the *Pended Workflow* folder in the
|
|
153
|
-
and click the "Send" button in the upper right.
|
|
154
|
-
1. Search in the response returned to Postman for the string "Certified in total" which indicates the prior
|
|
155
|
-
auth request was approved. You'll use this information in a later attestation.
|
|
156
|
-
1. Back in Inferno, scroll down in wait dialog and click the "click here to complete the test"
|
|
157
|
-
link to allow Inferno to evaluate the pended workflow.
|
|
158
|
-
1. The next two attestations ask whether the system displayed the claim as pended and approved at the
|
|
159
|
-
appropriate points in the workflow. Attest based on whether the correct strings were found in the
|
|
160
|
-
responses in the previous steps.
|
|
161
|
-
1. Two additional "User Action" dialogs will appear requesting additional `$submit` and `$inquire`
|
|
162
|
-
requests to demonstrate must support elements. This demo does not have any additional requests
|
|
163
|
-
and does not attempt to demonstrate all must support elements, so click the link to indicate
|
|
164
|
-
you are done submitting requests for each. Note that requests submitted during the workflow section
|
|
165
|
-
will be evaluated and you can inspect the results under the Demonstrate Element Support test
|
|
166
|
-
to see both passing and failing tests.
|
|
167
|
-
1. Once Inferno finishes evaluating the requests, the test will complete allowing you to review the
|
|
168
|
-
results, including warning and error messages as well as requests associated with each test.
|
|
169
|
-
|
|
170
|
-
The tests are expected to pass with the exception of the Must Support tests.
|
|
171
|
-
|
|
172
|
-
#### Optional Demo Modification: full-resource Subscription
|
|
173
|
-
|
|
174
|
-
This demo uses `id-only` notifications for Pended workflow. To see a demonstration of `full-resource`
|
|
175
|
-
notifications, replace the string `id-only` in the "Create Subscription Request" entry under the
|
|
176
|
-
"Subscription Setup" folder in the collection with the string `full-resource` (found in an extension
|
|
177
|
-
under the `_payload` element).
|
|
178
|
-
|
|
179
|
-
#### Optional Demo Modification: SMART Backend Services Auth
|
|
180
|
-
|
|
181
|
-
To use SMART Backend Services with the demo, choose the "SMART Backend Services" Client Security Type
|
|
182
|
-
option and replace the 3. Client Registration steps above with the following:
|
|
183
|
-
|
|
184
|
-
- In the **SMART JSON Web Key Set (JWKS)** input, put `https://inferno.healthit.gov/suites/custom/smart_stu2_2/.well-known/jwks.json`
|
|
185
|
-
- In the **Client Id** input, put `pas_demo_smart`
|
|
186
|
-
- Click the **SUBMIT** button
|
|
187
|
-
- A wait dialog will display asking the tester to confirm configuration of the client. Note the
|
|
188
|
-
FHIR endpoint and client id details
|
|
189
|
-
- Start an instance of the SMART App Launch STU2.2 test suite.
|
|
190
|
-
- Select the **3** Backend Services group from the list at the left and the click the "RUN TESTS"
|
|
191
|
-
button in the upper right.
|
|
192
|
-
- Fill in the following input values and then click "SUBMIT":
|
|
193
|
-
- **FHIR Endpoint**: from the wait dialog in the PAS Client suite
|
|
194
|
-
- **Scopes**: any scope string, e.g., `system/*.rs`
|
|
195
|
-
- **Client Id**: same value as in the corresponding input to the PAS Client tests, also displayed
|
|
196
|
-
in the wait dialog
|
|
197
|
-
- Find the access token to use for the data access request by opening test **3.2.05** Authorization
|
|
198
|
-
request succeeds when supplied correct information, click on the "REQUESTS" tab, clicking on the "DETAILS"
|
|
199
|
-
button, and expanding the "Response Body". Copy the "access_token" value, which will be a ~100 character
|
|
200
|
-
string of letters and numbers (e.g., eyJjbGllbnRfaWQiOiJzbWFydF9jbGllbnRfdGVzdF9kZW1vIiwiZXhwaXJhdGlvbiI6MTc0MzUxNDk4Mywibm9uY2UiOiJlZDI5MWIwNmZhMTE4OTc4In0)
|
|
201
|
-
- In Postman, select the *PAS Client Suite Demonstration* Collection in postman and go to the "Variables" tab
|
|
202
|
-
(see the collection's Overview tab for more details on what the variables control).
|
|
203
|
-
- In the current value for the **access_token** variable, put access token value copied from the SMART tests.
|
|
204
|
-
Make sure that the **session_url_path** variable has a current value of `/`.
|
|
205
|
-
- Back in Inferno, click link in the wait dialog confirming the configuration to continue the tests.
|
|
206
|
-
- A **Subscription Creation Test** wait dialog will appear.
|
|
207
|
-
|
|
208
|
-
Continue the tests according to step 4 around Subscription creation in the above instructions.
|
|
209
|
-
|
|
210
|
-
In this demonstration, the "Verify SMART Token Requests" test will also fail due to invalid
|
|
211
|
-
token requests sent intentionally by the SMART Backend Services server tests.
|
|
212
|
-
|
|
213
|
-
#### Optional Demo Modification: UDAP Client Credentials Auth
|
|
214
|
-
|
|
215
|
-
To use the UDAP Client Credentials with the demo, choose the "UDAP B2B Client Credentials" Client
|
|
216
|
-
Security Type option and replace the 3. Client Registration steps above with the following:
|
|
217
|
-
|
|
218
|
-
- In the **UDAP Client URI** input, put `http://localhost:4567/custom/udap_security/fhir`
|
|
219
|
-
- Click the **SUBMIT** button and a wait dialog will display asking the tester to perform UDAP dynamic
|
|
220
|
-
registration. Note the FHIR server endpoint displayed in the dialog.
|
|
221
|
-
- Start an instance of the UDAP Security Server test suite.
|
|
222
|
-
- Select the "Demo: Run Against the UDAP Security Client Suite" preset from the dropdown in the upper left.
|
|
223
|
-
- Select the **2** UDAP Client Credentials Flow group from the list at the left and the click the "RUN ALL TESTS"
|
|
224
|
-
button in the upper right.
|
|
225
|
-
- Update the **FHIR Server Base URL** input value to be the FHIR server endpoint from the wait dialog
|
|
226
|
-
in the PAS Client suite and then click "SUBMIT"
|
|
227
|
-
- Once the tests have completed, find the access token to use for the data access request by opening
|
|
228
|
-
test **2.3.01** OAuth token exchange request succeeds when supplied correct information, click
|
|
229
|
-
on the "REQUESTS" tab, clicking on the "DETAILS" button, and expanding the "Response Body".
|
|
230
|
-
Copy the "access_token" value, which will be a ~100 character string of letters and numbers (e.g., eyJjbGllbnRfaWQiOiJzbWFydF9jbGllbnRfdGVzdF9kZW1vIiwiZXhwaXJhdGlvbiI6MTc0MzUxNDk4Mywibm9uY2UiOiJlZDI5MWIwNmZhMTE4OTc4In0)
|
|
231
|
-
- In Postman, select the *PAS Client Suite Demonstration* Collection in postman and go to the "Variables" tab
|
|
232
|
-
(see the collection's Overview tab for more details on what the variables control).
|
|
233
|
-
- In the current value for the **access_token** variable, put access token value copied from the SMART tests.
|
|
234
|
-
Make sure that the **session_url_path** variable has a current value of `/`.
|
|
235
|
-
- In the PAS Client suite tab, click the link in the wait dialog to continue the tests. Do the same
|
|
236
|
-
for the next wait dialog that appears until a **Subscription Creation Test** wait dialog appears.
|
|
237
|
-
|
|
238
|
-
Continue the tests according to step 4 around Subscription creation in the above instructions.
|
|
239
|
-
|
|
240
|
-
In this demonstration, the "Verify UDAP Client Credentials Token Requests" test may fail due
|
|
241
|
-
to expired signatures if the test session has taken long enough.
|
|
242
|
-
|
|
243
|
-
## Auth Configuration Details
|
|
244
|
-
|
|
245
|
-
When running these tests there are 3 options for authentication, which also allows
|
|
246
|
-
Inferno to identify which session the requests are for. The choice is made when the
|
|
247
|
-
session is created with the selected Client Security Type option, which determines
|
|
248
|
-
what details the tester needs to provide during the Client Registration tests:
|
|
249
|
-
|
|
250
|
-
- **SMART Backend Services**: the system under test will manually register
|
|
251
|
-
with Inferno and request access tokens for use when accessing FHIR endpoints
|
|
252
|
-
as per the SMART Backend Services specification. It requires the
|
|
253
|
-
**SMART JSON Web Key Set (JWKS)** input to be populated with either a URL that resolves
|
|
254
|
-
to a JWKS or a raw JWKS in JSON format. Additionally, testers may provide
|
|
255
|
-
a **Client Id** if they want their client assigned a specific one.
|
|
256
|
-
- **UDAP B2B Client Credentials**: the system under test will dynamically register
|
|
257
|
-
with Inferno and request access tokens used to access FHIR endpoints
|
|
258
|
-
as per the UDAP specification. It requires the **UDAP Client URI** input
|
|
259
|
-
to be populated with the URI that the client will use when dynamically
|
|
260
|
-
registering with Inferno. This will be used to generate a client id (each
|
|
261
|
-
unique UDAP Client URI will always get the same client id).
|
|
262
|
-
- **Other Authentication**: Inferno will create a dedicated set of FHIR endpoints for this session
|
|
263
|
-
so that the system under test does not need to get access tokens or provide
|
|
264
|
-
them when interacting with Inferno during these tests. Since PAS requires
|
|
265
|
-
authentication of client systems, testers will be asked to attest that their
|
|
266
|
-
system supports another form of authentication, such as mutual authentication TLS.
|
|
267
|
-
This approach uses the **Session-specific URL path extension** input to create a
|
|
268
|
-
session-specific URL. This input can be provided for re-use across sessions, or
|
|
269
|
-
left blank to have Inferno generate a value.
|
|
270
|
-
|
|
271
|
-
## Response and Notification Content
|
|
272
|
-
|
|
273
|
-
To assist in testers getting started with the PAS Client tests quickly, Inferno will generate
|
|
274
|
-
conformant mocked `$submit` and `$inquire` operation responses and Subscription notifications.
|
|
275
|
-
However, the simple mocked messages may not drive the workflows of real systems in a way that allows
|
|
276
|
-
them to demonstrate their implementation of the PAS specification. Thus, Inferno also allows each message
|
|
277
|
-
returned or initiated by Inferno to be specified by the tester. These messages must themselves be
|
|
278
|
-
conformant to PAS specification requirements and additional test requirements in order for a test run to
|
|
279
|
-
serve as a demonstration of a conformant implementation.
|
|
280
|
-
|
|
281
|
-
The rest of this section provides details on how Inferno determines the content to use in responses
|
|
282
|
-
and notifications.
|
|
283
|
-
|
|
284
|
-
### Inferno Modifications of Tester-provided Responses and Notifications
|
|
285
|
-
|
|
286
|
-
Requests provided by testers will be modified by Inferno to try and populate details that testers won't
|
|
287
|
-
know ahead of time. These modifications fall into two categories:
|
|
288
|
-
- **Timestamps**: creation timestamps, such as those on Bundles, ClaimResponses, and event notifications,
|
|
289
|
-
will be updated or populated by Inferno so that they are in sync with the time the message is sent.
|
|
290
|
-
- **Resource Ids**: some resource ids will not be known ahead of time and will be added or updated by Inferno
|
|
291
|
-
including
|
|
292
|
-
- *Claim Id*: if the tester provides a `$submit` or `$inquire` response with `ClaimResponse.request` populated,
|
|
293
|
-
then Inferno will update it with the fullUrl of the Claim provided in the request. This avoids the need for
|
|
294
|
-
testers to know the Claim Id ahead of time which may be difficult for some systems.
|
|
295
|
-
- *ClaimResponse Id*: if the tester provides a Notification but has Inferno generate the `$submit` response,
|
|
296
|
-
then Inferno will update the focus to use the ClaimResponse id that it generates.
|
|
297
|
-
|
|
298
|
-
If the tester provides an input that is malformed in some way such that Inferno cannot get the details
|
|
299
|
-
that it needs to make the modifications, then the raw input will be used.
|
|
300
|
-
|
|
301
|
-
### Response and Notification Correspondence Requirements
|
|
302
|
-
|
|
303
|
-
Beyond the minor modifications described above, Inferno does not modify provided content to ensure that
|
|
304
|
-
they are consistent with each other or the time they are executed. For example, in the pended
|
|
305
|
-
workflow, it is up to the tester to ensure that if they provide responses for the `$submit` and `$inquire`
|
|
306
|
-
operations that they share whatever details, such as identifiers, needed to connect them together and drive
|
|
307
|
-
the workflow in their system. Timestamps not associated with messaging time such as when a prior authorization
|
|
308
|
-
response is valid are also not modified by Inferno. Unlike details that Inferno modifies as described above,
|
|
309
|
-
testers should have control over and/or knowledge of the necessary details and values to construct consistent
|
|
310
|
-
and working messages for Inferno to use.
|
|
311
|
-
|
|
312
|
-
### Tester-provided Response and Notification Inputs
|
|
313
|
-
|
|
314
|
-
The following test inputs control Inferno messaging behavior:
|
|
315
|
-
- **Claim approved response JSON**: If populated, this is used in the "Approval Workflow" group
|
|
316
|
-
to respond to `$submit` requests. The response needs to indicate to the system that the prior auth request has
|
|
317
|
-
been approved.
|
|
318
|
-
- **Claim denied response JSON**: If populated, this used in the "Denial Workflow" group
|
|
319
|
-
to respond to `$submit` requests. The response needs to indicate to the system that the prior auth request has
|
|
320
|
-
been denied.
|
|
321
|
-
- **Claim pended response JSON**: If populated, this used in the "Pended Workflow" group
|
|
322
|
-
to respond to `$submit` requests. The response needs to indicate to the system that the prior auth request has
|
|
323
|
-
been pended.
|
|
324
|
-
- **Claim updated notification JSON**: If populated, this used in the "Pended Workflow" group
|
|
325
|
-
as the event notification sent for the Subscription indicating that a decision has been finalized for the
|
|
326
|
-
pended prior auth request. The content of the notification needs to match the details of the Subscription
|
|
327
|
-
provided in the "Subscription Setup" group.
|
|
328
|
-
- **Inquire approved response JSON**: If populated, this used in the "Pended Workflow"
|
|
329
|
-
group to respond to `$inquire` requests. The response needs to indicate to the system that the
|
|
330
|
-
prior auth request has been approved.
|
|
331
|
-
|
|
332
|
-
### Generation Logic
|
|
333
|
-
|
|
334
|
-
When generating responses and notifications, Inferno uses the following logic. These conform to the
|
|
335
|
-
requirements of the PAS specification, but may not make sense in an actual workflow.
|
|
336
|
-
- **`$submit` and `$inquire` responses**: these responses are created mostly from the incoming request, specific details include:
|
|
337
|
-
- The Patient, insurer Organization, and requestor entity instances are pulled into the response
|
|
338
|
-
Bundle and referenced in the `patient`, `insurer`, and `requestor` elements respectively.
|
|
339
|
-
Note that get found by following references found in the submitted Claim instance. If relative
|
|
340
|
-
references are used in the Claim, the Claim entry `fullUrl` needs to be a absolute reference
|
|
341
|
-
and not a UUID, else the entries won't get pulled in correctly.
|
|
342
|
-
- In the ClaimResponse, the `identifier`, `type`, `status`, and `use` elements are pulled
|
|
343
|
-
in from the Claim in the request.
|
|
344
|
-
- The `Bundle.timestamp` and `ClaimResponse.created` timestamps are populated using the current time.
|
|
345
|
-
- The `ClaimResponse.outcome` is hardcoded to `complete`.
|
|
346
|
-
- For each `item` entry in the request Claim, a `ClaimResponse.item` entry is created with the
|
|
347
|
-
`itemSequence` value copied over, `itemPreAuthIssueDate` and `itemPreAuthPeriod` extensions
|
|
348
|
-
added using the current date and a month starting on the current date respectively,
|
|
349
|
-
and an adjudication entry with a `category` of `submitted` that contains the `reviewAction` extension with a
|
|
350
|
-
`reviewActionCode` that matches the current workflow: `A1` ("Certified in total") for approval,
|
|
351
|
-
`A3` ("Not Certified") for denial, and `A4` ("Pending") for pending.
|
|
352
|
-
- **Notification Bundle**: Inferno supports mocking both `id-only` and `full-resource` notifications.
|
|
353
|
-
The following details are relevant:
|
|
354
|
-
- Inferno pulls in details from the Subscription created for the test session to use in
|
|
355
|
-
creating the Notification, including the `topic` and the `subscription` reference.
|
|
356
|
-
- Inferno hardcodes the `status` as `active` and the `type` as `event-notification`.
|
|
357
|
-
- Inferno will always include a single `notification-event` entry with a `timestamp` of the current
|
|
358
|
-
time and with a `focus` that points to the ClaimResponse returned on the `$submit`.
|
|
359
|
-
If it cannot find the ClaimResponse reference from the `$submit` response returned
|
|
360
|
-
by Inferno, it will generate a random UUID (which isn't likely to work correctly when received).
|
|
361
|
-
- The subscription's `events-since-subscription-start` and the event's `event-number` will always
|
|
362
|
-
be 1 as Inferno is not able to track notifications across multiple sessions or runs.
|
|
363
|
-
- When generating a `full-resource` notification, Inferno will include `additional-context`
|
|
364
|
-
references for each entry in the `$submit` response Bundle other than the ClaimResponse
|
|
365
|
-
(which is already in the `focus`). Then it will include Notification Bundle entries for
|
|
366
|
-
each instance in the `$submit` response Bundle, including the ClaimResponse, with `reviewActionCode`
|
|
367
|
-
extensions updated to indicate approval using code `A1` ("Certified in total") for approval.
|
|
368
|
-
|
|
369
|
-
## Testing Limitations
|
|
370
|
-
|
|
371
|
-
### Private X12 details
|
|
372
|
-
|
|
373
|
-
HIPAA [requires](https://hl7.org/fhir/us/davinci-pas/STU2/regulations.html) electronic prior authorization
|
|
374
|
-
processing to use the X12 278 standard. While recent CMS rule-making suggests that [this requirement
|
|
375
|
-
will not be enforced in the future](https://www.cms.gov/newsroom/fact-sheets/cms-interoperability-and-prior-authorization-final-rule-cms-0057-f),
|
|
376
|
-
the current PAS IG relies heavily on X12. As the IG authors note at the
|
|
377
|
-
top of the [IG home page](https://hl7.org/fhir/us/davinci-pas/STU2/index.html):
|
|
378
|
-
|
|
379
|
-
> Note that this implementation guide is intended to support mapping between FHIR and X12 transactions. To respect
|
|
380
|
-
> X12 intellectual property, all mapping and X12-specific terminology information will be solely published by X12
|
|
381
|
-
> and made available in accordance with X12 rules - which may require membership and/or payment. Please see this
|
|
382
|
-
> [Da Vinci External Reference page](https://confluence.hl7.org/display/DVP/Da+Vinci+Reference+to+External+Standards+and+Terminologies)
|
|
383
|
-
> for details on how to get this mapping.
|
|
384
|
-
>
|
|
385
|
-
> There are many situationally required fields that are specified in the X12 TRN03 guide that do not have guidance
|
|
386
|
-
> in this Implementation Guide. Implementers need to consult the X12 PAS guides to know the requirements for these
|
|
387
|
-
> fields.
|
|
388
|
-
>
|
|
389
|
-
> Several of the profiles will require use of terminologies that are part of X12 which we anticipate being made
|
|
390
|
-
> publicly available. At such time as this occurs, the implementation guide will be updated to bind to these as
|
|
391
|
-
> external terminologies.
|
|
392
|
-
|
|
393
|
-
The implications of this reliance on proprietary information that is not publicly available means that this test
|
|
394
|
-
kit:
|
|
395
|
-
|
|
396
|
-
- *Cannot verify the correct usage of X12-based terminology*: terminology requirements for all elements bound to X12
|
|
397
|
-
value sets will not be validated.
|
|
398
|
-
- *Cannot verify the meaning of codes*: validation that a given response conveys something specific, e.g., approval
|
|
399
|
-
or pending, is not performed.
|
|
400
|
-
- *Cannot verify matching semantics on inquiries*: no checking of the identity of the ClaimResponse returned for an
|
|
401
|
-
inquiry, e.g., that it matches the input or the original request.
|
|
402
|
-
|
|
403
|
-
These limitations may be removed in future versions of these tests. In the meantime, testers should consider these
|
|
404
|
-
requirements to be verified through attestation and should not represent their systems to have passed these tests
|
|
405
|
-
if these requirements are not met.
|
|
406
|
-
|
|
407
|
-
### Subscription Details
|
|
408
|
-
|
|
409
|
-
Subscription details in the PAS 2.0.1 specification are relatively underspecified and the
|
|
410
|
-
[published 2.1.0 version of the
|
|
411
|
-
specification](https://hl7.org/fhir/us/davinci-pas/STU2.1/specification.html#subscription)
|
|
412
|
-
makes significant changes, including requiring `full-resource` and updating details such as
|
|
413
|
-
the filter criteria.
|
|
414
|
-
|
|
415
|
-
Based on the immaturity of the 2.0.1 requirements around Subscriptions, these tests implement and check for
|
|
416
|
-
the mechanics of Subscriptions and notifications, but do not look closely at the details. For example,
|
|
417
|
-
`id-only` and `full-resource` are supported and the filter criteria format is not checked. Future versions
|
|
418
|
-
of these tests may be more stringent.
|
|
419
|
-
|
|
420
|
-
Additionally, to test Subscriptions and pending workflows, a new Subscription must be created for each
|
|
421
|
-
test session, which may require testers to re-initialize previously-created Subscriptions. Future versions
|
|
422
|
-
of these tests may relax this requirement and feedback on whether this would reduce burden and how this
|
|
423
|
-
might look are welcome.
|
|
424
|
-
|
|
425
|
-
### Future Details
|
|
426
|
-
|
|
427
|
-
The PAS IG places additional requirements on clients that are not currently tested by this test kit, including
|
|
428
|
-
|
|
429
|
-
- Prior Authorization update workflows
|
|
430
|
-
- Requests for additional information handled through the CDex framework
|
|
431
|
-
- PDF, CDA, and JPG attachments
|
|
432
|
-
- US Core profile support for supporting information
|
|
433
|
-
- The ability to handle responses containing all PAS-defined profiles and must support elements
|
|
434
|
-
- Most details requiring manual review of the client system, e.g., the requirement that clinicians can update
|
|
435
|
-
details of the prior authorization request before submitting them
|
|
436
|
-
|
|
437
|
-
These and any other requirements found in the PAS IG may be tested in future versions of these tests.
|
|
438
|
-
|
|
439
|
-
### Known Issues
|
|
440
|
-
|
|
441
|
-
Testing has identified issues with the source IG that result in spurious failures.
|
|
442
|
-
Tests impacted by these issues have an indication in their documentations. The full
|
|
443
|
-
list of known issues can be found on the [repository's issues page with the 'source ig issue'
|
|
444
|
-
label](https://github.com/inferno-framework/davinci-pas-test-kit/labels/source%20ig%20issue).
|
|
@@ -1,168 +0,0 @@
|
|
|
1
|
-
The Da Vinci PAS Server Suite validates the conformance of server systems
|
|
2
|
-
to the STU 2 version of the HL7® FHIR®
|
|
3
|
-
[Da Vinci Prior Authorization Support Implementation Guide](https://hl7.org/fhir/us/davinci-pas/STU2/).
|
|
4
|
-
|
|
5
|
-
## Scope
|
|
6
|
-
|
|
7
|
-
These tests are a **DRAFT** intended to allow PAS server implementers to perform
|
|
8
|
-
preliminary checks of their servers against PAS IG requirements and [provide
|
|
9
|
-
feedback](https://github.com/inferno-framework/davinci-pas-test-kit/issues)
|
|
10
|
-
on the tests. Future versions of these tests may validate other
|
|
11
|
-
requirements and may change the test validation logic.
|
|
12
|
-
|
|
13
|
-
## Test Methodology
|
|
14
|
-
|
|
15
|
-
Inferno will simulate a client and make a series of prior authorization requests to the
|
|
16
|
-
server under test. Over the course of these requests, Inferno will seek to observe
|
|
17
|
-
conformant handling of PAS requirements, including
|
|
18
|
-
- The ability of the server to use PAS API interactions to communicate
|
|
19
|
-
- Approval of a prior authorization request
|
|
20
|
-
- Denial of a prior authorization request
|
|
21
|
-
- Pending of a prior authorization request and a subsequent final decision
|
|
22
|
-
- Inability to process a prior authorization request
|
|
23
|
-
- The ability of the server to handle the full scope of data required by PAS, including
|
|
24
|
-
- Ability to process prior auth requests and inquiries with all PAS profiles and all must support elements on those profiles
|
|
25
|
-
- Ability to return responses that demonstrate the use of all PAS profiles and all must support elements on those profiles
|
|
26
|
-
|
|
27
|
-
Because the business logic that determines decisions and the elements populated in responses
|
|
28
|
-
Is outside of the PAS specification and will vary between implementers, testers
|
|
29
|
-
are required to provide the requests that Inferno will make to the server.
|
|
30
|
-
|
|
31
|
-
All requests and responses will be checked for conformance to the PAS
|
|
32
|
-
IG requirements individually and used in aggregate to determine whether
|
|
33
|
-
required features and functionality are present. HL7® FHIR® resources are
|
|
34
|
-
validated with the Java validator using `tx.fhir.org` as the terminology server.
|
|
35
|
-
|
|
36
|
-
These tests do not currently test the full scope of the IG. See the *Testing Limitations* section below
|
|
37
|
-
for more details about the current scope of the tests and the reasons that some details have been left out.
|
|
38
|
-
|
|
39
|
-
## Running the Tests
|
|
40
|
-
|
|
41
|
-
### Quick Start
|
|
42
|
-
|
|
43
|
-
Execution of these tests require a significant amount of tester input in the
|
|
44
|
-
form of requests that Inferno will make against the server under test.
|
|
45
|
-
|
|
46
|
-
If you would like to try out the tests using examples from the IG against the
|
|
47
|
-
[public reference server endpoint](https://prior-auth.davinci.hl7.org/fhir) ([code on github](https://github.com/HL7-DaVinci/prior-auth)), you can do so by
|
|
48
|
-
1. Selecting the *Prior Authorization Support Reference Implementation* option from the Preset dropdown in the upper left
|
|
49
|
-
2. Clicking the *Run All Tests* button in the upper right
|
|
50
|
-
3. Clicking the *Submit* button at the bottom of the input dialog
|
|
51
|
-
|
|
52
|
-
You can run these tests using your own server by updating the "FHIR Server Endpoint URL" and "OAuth Credentials" inputs.
|
|
53
|
-
|
|
54
|
-
Note that:
|
|
55
|
-
- the inputs for these tests are not complete and systems are not expected to pass the tests based on them.
|
|
56
|
-
- the public reference server has not been updated to reflect the STU2 version that these tests target,
|
|
57
|
-
so expect some additional failures when testing against it.
|
|
58
|
-
|
|
59
|
-
## Test Configuration Details
|
|
60
|
-
|
|
61
|
-
The details provided here supplement the documentation of individual fields in the input dialog
|
|
62
|
-
that appears when initiating a test run.
|
|
63
|
-
|
|
64
|
-
### Server identification
|
|
65
|
-
|
|
66
|
-
Requests will be made to the `/Claim/$submit` and `/Claim/$inquire` endpoints under the url provided in the "FHIR Server Endpoint URL" field.
|
|
67
|
-
|
|
68
|
-
### Authentication
|
|
69
|
-
|
|
70
|
-
The PAS IG states that
|
|
71
|
-
|
|
72
|
-
> "PAS Servers **SHOULD** support server-server OAuth… In a future release of this guide, direction will limit the option to [require] server-server OAuth."
|
|
73
|
-
|
|
74
|
-
The PAS test kit currently assumes that the handshake has already occurred and requires
|
|
75
|
-
that a bearer token be provided in the “OAuth Credentials / Access Token” configuration
|
|
76
|
-
field. Inferno will submit this token on all requests it makes to the server as a part of
|
|
77
|
-
executing the tests. A complete backend server authentication handshake may be supported
|
|
78
|
-
in future versions of the test kit.
|
|
79
|
-
|
|
80
|
-
### Payload
|
|
81
|
-
|
|
82
|
-
All other inputs are for providing bundles for Inferno to submit as a part of the tests. To avoid placing
|
|
83
|
-
requirements on the business logic, Inferno does not have standard requests to send as a part of the tests
|
|
84
|
-
and instead relies on the tester to provide the requests that Inferno will make.
|
|
85
|
-
|
|
86
|
-
For single-request fields (e.g., “PAS Submit Request Payload for Approval Response”), the input must be a json-encoded FHIR bundle.
|
|
87
|
-
|
|
88
|
-
For multiple-request fields (e.g., “Additional PAS Submit Request Payloads”), the input must be a json array of json-encoded FHIR bundles (e.g., [fhir-bundle-1, fhir-bundle-2, …] where each fhir-bundle-n is a full bundle).
|
|
89
|
-
|
|
90
|
-
### Subscription
|
|
91
|
-
|
|
92
|
-
To provide updates on prior authorization requests that have been pended because a final answer will take longer than
|
|
93
|
-
the allowed response window, servers need to support FHIR Subscriptions. Subscriptions are made at the level of the
|
|
94
|
-
Organization submitting the prior authorization requests and so is expected to be performed once when a provider
|
|
95
|
-
system registers with a specific payer.
|
|
96
|
-
|
|
97
|
-
Inferno supports that workflow by splitting out Subscription setup tests into a group that can be run before the
|
|
98
|
-
pended workflow group. Inferno assumes that the Subscriptions API is located under the same FHIR base URL as
|
|
99
|
-
the `Claim/$submit` operation and that it uses the same authentication. Testers will provide the following inputs:
|
|
100
|
-
- **Pended Prior Authorization Subscription**: A Subscription body for Inferno to submit to the server under test.
|
|
101
|
-
When submitted to the server under test, it should cause notifications to be generated when pended prior
|
|
102
|
-
authorization requests submitted by Inferno are updated. Inferno will modify it to ensure that it points to
|
|
103
|
-
the correct Inferno notification endpoint.
|
|
104
|
-
- **Notification Access Token**: An access token that the server under test will send to Inferno on notifications
|
|
105
|
-
so that the request gets associated with this test session. The token must be provided as a Bearer token in the
|
|
106
|
-
Authorization header of HTTP requests sent to Inferno.
|
|
107
|
-
|
|
108
|
-
During the pended workflow test, testers will demonstrate that an update to the submitted and pended prior authorization
|
|
109
|
-
request causes the Subscription to trigger and send a notification to Inferno.
|
|
110
|
-
|
|
111
|
-
## Testing Limitations
|
|
112
|
-
|
|
113
|
-
### Private X12 details
|
|
114
|
-
|
|
115
|
-
HIPAA [requires](https://hl7.org/fhir/us/davinci-pas/STU2/regulations.html) electronic prior authorization
|
|
116
|
-
processing to use the X12 278 standard. While recent CMS rule-making suggests that [this requirement
|
|
117
|
-
will not be enforced in the future](https://www.cms.gov/newsroom/fact-sheets/cms-interoperability-and-prior-authorization-final-rule-cms-0057-f),
|
|
118
|
-
the current PAS IG relies heavily on X12. As the IG authors note at the
|
|
119
|
-
top of the [IG home page](https://hl7.org/fhir/us/davinci-pas/STU2/):
|
|
120
|
-
|
|
121
|
-
> Note that this implementation guide is intended to support mapping between FHIR and X12 transactions. To respect
|
|
122
|
-
> X12 intellectual property, all mapping and X12-specific terminology information will be solely published by X12
|
|
123
|
-
> and made available in accordance with X12 rules - which may require membership and/or payment. Please see this
|
|
124
|
-
> [Da Vinci External Reference page](https://confluence.hl7.org/display/DVP/Da+Vinci+Reference+to+External+Standards+and+Terminologies)
|
|
125
|
-
> for details on how to get this mapping.
|
|
126
|
-
>
|
|
127
|
-
> There are many situationally required fields that are specified in the X12 TRN03 guide that do not have guidance
|
|
128
|
-
> in this Implementation Guide. Implementers need to consult the X12 PAS guides to know the requirements for these
|
|
129
|
-
> fields.
|
|
130
|
-
>
|
|
131
|
-
> Several of the profiles will require use of terminologies that are part of X12 which we anticipate being made
|
|
132
|
-
> publicly available. At such time as this occurs, the implementation guide will be updated to bind to these as
|
|
133
|
-
> external terminologies.
|
|
134
|
-
|
|
135
|
-
The implications of this reliance on proprietary information that is not publicly available means that this test
|
|
136
|
-
kit:
|
|
137
|
-
|
|
138
|
-
- Cannot verify the correct usage of X12-based terminology: terminology requirements for all elements bound to X12
|
|
139
|
-
value sets will not be validated.
|
|
140
|
-
- Cannot verify the meaning of codes: validation that a given response conveys something specific, e.g., approval
|
|
141
|
-
or pending, is not performed.
|
|
142
|
-
- Cannot verify matching semantics on inquiries: no checking of the identity of the ClaimResponse returned for an
|
|
143
|
-
inquiry, e.g., that it matches the input or the original request.
|
|
144
|
-
|
|
145
|
-
These limitations may be removed in future versions of these tests. In the meantime, testers should consider these
|
|
146
|
-
requirements to be verified through attestation and should not represent their systems to have passed these tests
|
|
147
|
-
if these requirements are not met.
|
|
148
|
-
|
|
149
|
-
### Future Details
|
|
150
|
-
|
|
151
|
-
The PAS IG places additional requirements on servers that are not currently tested by this test kit, including
|
|
152
|
-
|
|
153
|
-
- Prior Authorization update workflows
|
|
154
|
-
- Requests for additional information handled through the CDex framework
|
|
155
|
-
- PDF, CDA, and JPG attachments
|
|
156
|
-
- US Core profile support for supporting information
|
|
157
|
-
- Inquiry matching and subsetting logic
|
|
158
|
-
- Inquiry requests from non-submitting systems
|
|
159
|
-
- Collection of metrics
|
|
160
|
-
|
|
161
|
-
These and any other requirements found in the PAS IG may be tested in future versions of these tests.
|
|
162
|
-
|
|
163
|
-
### Known Issues
|
|
164
|
-
|
|
165
|
-
Testing has identified issues with the source IG that result in spurious failures.
|
|
166
|
-
Tests impacted by these issues have an indication in their documentations. The full
|
|
167
|
-
list of known issues can be found on the [repository's issues page with the 'source ig issue'
|
|
168
|
-
label](https://github.com/inferno-framework/davinci-pas-test-kit/labels/source%20ig%20issue).
|