davinci_pas_test_kit 0.9.0 → 0.9.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 8afec0fe44554f72cce5bfd53e2ec230aac6b9cf7a1c9619a2e7264f3e09a2ba
-  data.tar.gz: 02c6532a6c3e541a704df48a875e20bf73282e4d8fbf7cd590c6541d7d1183f9
+  metadata.gz: 35fff0ddc7e7badcd0fe5e9927f9bbafc7be123f908f4eed1f81c8f777189ef4
+  data.tar.gz: 36fa5c2af21fb2ca92ff958a0f96d97aed08dd45c1bdd454cce2f2a4aabe5af1
 SHA512:
-  metadata.gz: 2a198d440407b88f2c9fef9002f36ece049baec615418d8a538a14d3314551366546331d44cea15b12e433cfbb25c5e8f087b71d45fa2a66c404618a2f1a4f58
-  data.tar.gz: c21b95655561c420a0a28efaf222d0ad0a480b17aa1dc53c4d2faeee0322bc6de5395c82162197dfd9e748dbf21c58438b1a9a978190f75af10a277accc0af3a
+  metadata.gz: 954d086d05f047336a216d2d72947ca8d8d1ffaf944a3b29174a15ea7fd73fe75d6a9e26552af08b20d7b33917102903ec9e98f90000fd2228697ab9cb25defb
+  data.tar.gz: 8ed7048ddeaad521eda54110707aa8a55e2e151c0f37c2f0a35ba5a57f2823c121e4b5d97796166340afbda10242650a2a83fe6244a6981d74ae5cf9472c4537

data/lib/davinci_pas_test_kit/client_suite.rb

@@ -20,175 +20,7 @@ module DaVinciPASTestKit
     id :davinci_pas_client_suite_v201
     title 'Da Vinci PAS Client Suite v2.0.1'
     version VERSION
-    description %(
-      The Da Vinci PAS Test Kit Client Suite validates the conformance of client
-      systems to the STU 2 version of the HL7® FHIR®
-      [Da Vinci Prior Authorization Support Implementation Guide](https://hl7.org/fhir/us/davinci-pas/STU2/).
-
-      ## Scope
-
-      These tests are a **DRAFT** intended to allow PAS client implementers to perform
-      preliminary checks of their clients against PAS IG requirements and [provide
-      feedback](https://github.com/inferno-framework/davinci-pas-test-kit/issues)
-      on the tests. Future versions of these tests may validate other
-      requirements and may change the test validation logic.
-
-      ## Test Methodology
-
-      Inferno will simulate a PAS server for the client under test to interact with. The client
-      will be expected to initiate requests to the server and demonstrate its ability to react
-      to the returned responses. Over the course of these interactions,
-      Inferno will seek to observe conformant handling of PAS requirements, including
-      - The ability of the client to initiate and react to
-          - The approval of a prior authorization request
-          - The denial of a prior authorization request
-          - The pending of a prior authorization request and a subsequent final decision
-      - The ability of the client to provide data covering the full scope of required by PAS, including
-          - The ability to send prior auth requests and inquiries with all PAS profiles and all must support elements on
-            those profiles
-          - The ability to handle responses that contain all PAS profiles and all must support elements on those
-            profiles (not included in the current version of these tests)
-
-      Because X12 details, including coded values indicating details like “denied” and “pended”,
-      are not public, Inferno is not currently able to generate a full set of responses to requests
-      or otherwise provide details on specific codes used to represent those concepts
-      and is limited to responses that look similar to the examples in the IG (e.g., [here](https://hl7.org/fhir/us/davinci-pas/STU2/Bundle-ReferralAuthorizationResponseBundleExample.html)).
-      Thus,
-
-      - In order to demonstrate specific workflows, namely pend and denial, users will need to provide the expected
-        response for Inferno to send back
-      - The current tests do not return to the client all PAS profiles and must support elements to confirm support.
-
-      For further details on limitations of these tests, see the *Testing Limitations* section below.
-
-      All requests and responses will be checked for conformance to the PAS
-      IG requirements individually and used in aggregate to determine whether
-      required features and functionality are present. HL7® FHIR® resources are
-      validated with the Java validator using `tx.fhir.org` as the terminology server.
-
-      ## Running the Tests
-
-      ### Quick Start
-
-      For Inferno to simulate a server that always returns approved responses, it needs
-      only to know the bearer token that the client will send on requests, for which there are two options.
-
-      1. If you want to choose your own bearer token, then
-          1. Select the "2. PAS Client Validation" test from the list on the left.
-          2. Click the '*Run All Tests*' button on the right.
-          3. In the "access_token" field, enter the bearer token that will be sent by the client under test (as part
-             of the Authorization header - Bearer: <provided value>).
-          4. Click the '*Submit*' button at the bottom of the dialog.
-      2. If you want to use a client_id to obtain an access token, then
-          1. Click the '*Run All Tests*' button on the right.
-          2. Provide the client's registered id "client_id" field of the input (NOTE, Inferno doesn't support the
-             registration API, so this must be obtained from another system or configured manually).
-          3. Click the '*Submit*' button at the bottom of the dialog.
-          4. Make a token request that includes the specified client id to the
-             `<inferno host>/custom/davinci_pas_client_suite_v201/mock_auth/token` endpoint to get
-             an access token to use on the request of the requests.
-
-      In either case, the tests will continue from that point, requesting the user to
-      direct the client to make certain requests to demonstrate PAS client capabilities.
-
-      Note: authentication options for these tests have not been finalized and are subject to change.
-
-      ### Complete Setup
-
-      The *Quick Start* approach does not test pended or deny workflows. To test these, provide a
-      json-encoded FHIR bundle in the "Claim pended response JSON" and "Claim deny response JSON" input field after
-      clicking the '*Run All Tests*' button. These responses will be echoed back when a request
-      is made during the corresponding test.
-
-      ### Postman-based Demo
-
-      If you do not have a PAS client but would like to try the tests out, you can use
-      [this postman collection](https://raw.githubusercontent.com/inferno-framework/davinci-pas-test-kit/blob/main/config/PAS%20Test%20Kit%20Client%20Test%20Demo.postman_collection.json)
-      to make requests against Inferno. The following requests and example responses from that collection can be used.
-
-      - Configuration
-        - *Deny Response* example under the *Homecare Prior Authorization Request*: use as the value of the
-          "Claim denied response JSON" input field. NOTE: this contains a placeholder code `DENIEDCODE` for the
-          X12 code representing the denied status. Replace with the X12-specified code before providing to Inferno
-          to accurately replicate a denial workflow for the client under test.
-        - *Pend Response* example under the *Medical Services Prior Authorization Request*: use as the value of the
-          "Claim pended response JSON" input field. NOTE: this contains a placeholder code `PENDEDCODE` for the
-          X12 code representing the pended status. Replace with the X12-specified code before providing to Inferno
-          to accurately replicate a pend workflow for the client under test.
-      - Submissions
-        - *mock token*: for submitting a client id to get back an access token to use on the rest of the tests. Set the
-          collection's access_token variable to the result.
-        - *Referral Prior Authorization Request*: use for the "Approval" workflow test submission.
-        - *Medical Services Prior Authorization Request*: use for the "Pended" workflow test submission.
-        - *Medical Services Inquiry Request*: use for the "Pended" workflow test inquiry.
-
-      No additional requests are present to submit as a part of the must support tests, so
-      testers can simply click the link to indicate they are done submitting requests. Note
-      that the requests within the Postman client are not expected to fully pass the tests as they
-      do not contain all must support items.
-
-      ## Testing Limitations
-
-      ### Private X12 details
-
-      HIPAA [requires](https://hl7.org/fhir/us/davinci-pas/STU2/regulations.html) electronic prior authorization
-      processing to use the X12 278 standard. While recent CMS rule-making suggests that [this requirement
-      will not be enforced in the future](https://www.cms.gov/newsroom/fact-sheets/cms-interoperability-and-prior-authorization-final-rule-cms-0057-f),
-      the current PAS IG relies heavily on X12.  As the IG authors note at the
-      top of the [IG home page](https://hl7.org/fhir/us/davinci-pas/STU2/index.html):
-
-      > Note that this implementation guide is intended to support mapping between FHIR and X12 transactions. To respect
-      > X12 intellectual property, all mapping and X12-specific terminology information will be solely published by X12
-      > and made available in accordance with X12 rules - which may require membership and/or payment. Please see this
-      > [Da Vinci External Reference page](https://confluence.hl7.org/display/DVP/Da+Vinci+Reference+to+External+Standards+and+Terminologies)
-      > for details on how to get this mapping.
-      >
-      > There are many situationally required fields that are specified in the X12 TRN03 guide that do not have guidance
-      > in this Implementation Guide. Implementers need to consult the X12 PAS guides to know the requirements for these
-      > fields.
-      >
-      > Several of the profiles will require use of terminologies that are part of X12 which we anticipate being made
-      > publicly available. At such time as this occurs, the implementation guide will be updated to bind to these as
-      > external terminologies.
-
-      The implications of this reliance on proprietary information that is not publicly available means that this test
-      kit:
-
-      - Cannot verify the correct usage of X12-based terminology: terminology requirements for all elements bound to X12
-        value sets will not be validated.
-      - Cannot verify the meaning of codes: validation that a given response conveys something specific, e.g., approval
-        or pending, is not performed.
-      - Cannot verify matching semantics on inquiries: no checking of the identity of the ClaimResponse returned for an
-        inquiry, e.g., that it matches the input or the original request.
-
-      These limitations may be removed in future versions of these tests. In the meantime, testers should consider these
-      requirements to be verified through attestation and should not represent their systems to have passed these tests
-      if these requirements are not met.
-
-      ### Underspecified Subscription Details
-
-      The current PAS specification around subscriptions and notifications
-      is not detailed enough to support testing. Notably,
-      - There are no examples of what a notification payload looks like
-      - There is no instruction on how to turn the notification payload into an inquiry
-
-      Once these details have been clarified, validation of the notification workflows
-      will be added to these tests.
-
-      ### Future Details
-
-      The PAS IG places additional requirements on clients that are not currently tested by this test kit, including
-
-      - Prior Authorization update workflows
-      - Requests for additional information handled through the CDex framework
-      - PDF, CDA, and JPG attachments
-      - US Core profile support for supporting information
-      - The ability to handle responses containing all PAS-defined profiles and must support elements
-      - Most details requiring manual review of the client system, e.g., the requirement that clinicians can update
-        details of the prior authorization request before submitting them
-
-      These and any other requirements found in the PAS IG may be tested in future versions of these tests.
-    )
+    description File.read(File.join(__dir__, 'docs', 'client_suite_description_v201.md'))
 
     links [
       {

data/lib/davinci_pas_test_kit/custom_groups/v2.0.1/{claim_status/pas_claim_status_test.rb → claim_response_decision/pas_claim_response_decision_test.rb}

@@ -3,17 +3,20 @@
 
 module DaVinciPASTestKit
   module DaVinciPASV201
-    class PasClaimStatusTest < Inferno::Test
+    class PasClaimResponseDecisionTest < Inferno::Test
       # include URLs // used for attestation experiment - see below
 
-      id :prior_auth_claim_status
-      title 'Server returns the expected authorization response'
+      id :prior_auth_claim_response_decision_validation
+      title 'Server response includes the expected decision code in the ClaimResponse instance'
       description %(
-        This test aims to confirm that the status of the prior authorization matches
-        the anticipated status for the workflow under examination.
-        (NOT YET IMPLEMENTED)
+        This test aims to confirm that the decision in the returned ClaimResponse matches
+        the decision code required for the workflow under examination.
+        This test is not yet implemented due to limitations in the IG (see details
+        [here](https://github.com/inferno-framework/davinci-pas-test-kit/blob/main/lib/davinci_pas_test_kit/docs/server_suite_description_v201.md#testing-limitations)).
+        It is currently optional and will always be skipped, but will be implemented in the future.
       )
       uses_request :pa_submit
+      optional # optional and skipped until implemented
 
       def status
         if use_case == 'approval'
@@ -24,6 +27,7 @@ module DaVinciPASTestKit
       end
 
       run do
+        skip
         # Experiment with extraction of statuses and use in an attestation
         # Not used due to the following problems:
         # - no real clients to test with
@@ -82,27 +86,6 @@ module DaVinciPASTestKit
         # )
         #
         # end of experiment with attestation code
-
-        # TODO: Implement subscription for pended: Inferno will subscribe to the server to receive notification
-        # when the submitted claim status will be updated.
-        if use_case == 'pended'
-          # rubocop:disable Layout/LineLength
-          wait(
-            identifier: use_case,
-            message: %(
-              Inferno has received a 'Pended' claim response as expected.
-
-              Please
-              **[click
-              here](#{Inferno::Application['base_url']}/custom/davinci_pas_server_suite_v201/resume_after_notification?use_case=#{use_case})**
-              when the status of this claim has been finalized to inform Inferno to resume testing.
-
-              Future versions of this test may implement automated monitoring
-              capabilities described in the implementation guide.
-            )
-          )
-          # rubocop:enable Layout/LineLength
-        end
       end
     end
   end

data/lib/davinci_pas_test_kit/custom_groups/v2.0.1/must_support/pas_client_must_support_requirement_test.rb

@@ -110,7 +110,7 @@ module DaVinciPASTestKit
           @@resource_type = @resource_type = type # rubocop:disable Style/ClassVars
           perform_must_support_test(resources)
         end
-        validate_must_support
+        validate_must_support(false)
       end
     end
   end

data/lib/davinci_pas_test_kit/custom_groups/v2.0.1/must_support/pas_server_must_support_requirement_test.rb

@@ -14,6 +14,9 @@ module DaVinciPASTestKit
         PAS Device Request, or PAS Nutrition Order) is observed with all of its must support elements
       )
       description %(
+        **USER INPUT VALIDATION**: This test validates input provided by the user instead of the system under test.
+        Errors encountered will be treated as a skip instead of a failure.
+
         The PAS IG includes four profiles for providing the specifics of the service or product requested
         in the prior authorization request. Any one of these profiles can be referenced in
         the must support element `Claim.item.extension:requestedService`:
@@ -109,7 +112,7 @@ module DaVinciPASTestKit
           @@resource_type = @resource_type = type # rubocop:disable Style/ClassVars
           perform_must_support_test(resources)
         end
-        validate_must_support
+        validate_must_support(true)
       end
     end
   end

data/lib/davinci_pas_test_kit/custom_groups/v2.0.1/notification/pas_subscription_notification_test.rb

@@ -0,0 +1,40 @@
+module DaVinciPASTestKit
+  module DaVinciPASV201
+    class PasUpdateNotificationTest < Inferno::Test
+      id :prior_auth_claim_response_update_notification_validation
+      title 'Server notifies the client that the pended claim was updated.'
+      description %(
+        This test validates that the server can notify the client that a final
+        decision has been made about a pended claim so that the client can query
+        for the details. Currently, testers attest that the decision on the prior
+        authorization request has been finalized so that Inferno can check the rest of
+        the pended workflow. In the future, Inferno will validate that the server
+        can accept requests for a subscription and send notifications alerting the client
+        to the availability of updates to the prior authorization request (see details on this limitation
+        [here](https://github.com/inferno-framework/davinci-pas-test-kit/blob/main/lib/davinci_pas_test_kit/docs/server_suite_description_v201.md#testing-limitations)).
+      )
+
+      run do
+        # rubocop:disable Layout/LineLength
+        wait(
+          identifier: 'pended',
+          message: %(
+            Inferno has received a 'Pended' claim response indicating that a final decision
+            has not yet been made on the prior authorization request.
+
+            Please
+            **[click
+            here](#{Inferno::Application['base_url']}/custom/davinci_pas_server_suite_v201/resume_after_notification?use_case=pended)**
+            when the status of this claim has been finalized to inform Inferno to resume testing.
+
+            Future versions of this test will validate subscription-based notifications as
+            described within the implementation guide (see
+            [here](https://github.com/inferno-framework/davinci-pas-test-kit/blob/main/lib/davinci_pas_test_kit/docs/server_suite_description_v201.md#testing-limitations)
+            for more details on this current limitation).
+          )
+        )
+        # rubocop:enable Layout/LineLength
+      end
+    end
+  end
+end

data/lib/davinci_pas_test_kit/docs/client_suite_description_v201.md

@@ -0,0 +1,167 @@
+The Da Vinci PAS Test Kit Client Suite validates the conformance of client
+systems to the STU 2 version of the HL7® FHIR®
+[Da Vinci Prior Authorization Support Implementation Guide](https://hl7.org/fhir/us/davinci-pas/STU2/).
+
+## Scope
+
+These tests are a **DRAFT** intended to allow PAS client implementers to perform
+preliminary checks of their clients against PAS IG requirements and [provide
+feedback](https://github.com/inferno-framework/davinci-pas-test-kit/issues)
+on the tests. Future versions of these tests may validate other
+requirements and may change the test validation logic.
+
+## Test Methodology
+
+Inferno will simulate a PAS server for the client under test to interact with. The client
+will be expected to initiate requests to the server and demonstrate its ability to react
+to the returned responses. Over the course of these interactions,
+Inferno will seek to observe conformant handling of PAS requirements, including
+- The ability of the client to initiate and react to
+    - The approval of a prior authorization request
+    - The denial of a prior authorization request
+    - The pending of a prior authorization request and a subsequent final decision
+- The ability of the client to provide data covering the full scope of required by PAS, including
+    - The ability to send prior auth requests and inquiries with all PAS profiles and all must support elements on
+    those profiles
+    - The ability to handle responses that contain all PAS profiles and all must support elements on those
+    profiles (not included in the current version of these tests)
+
+Because X12 details, including coded values indicating details like “denied” and “pended”,
+are not public, Inferno is not currently able to generate a full set of responses to requests
+or otherwise provide details on specific codes used to represent those concepts
+and is limited to responses that look similar to the examples in the IG (e.g., [here](https://hl7.org/fhir/us/davinci-pas/STU2/Bundle-ReferralAuthorizationResponseBundleExample.html)).
+Thus,
+
+- In order to demonstrate specific workflows, namely pend and denial, users will need to provide the expected
+response for Inferno to send back
+- The current tests do not return to the client all PAS profiles and must support elements to confirm support.
+
+For further details on limitations of these tests, see the *Testing Limitations* section below.
+
+All requests and responses will be checked for conformance to the PAS
+IG requirements individually and used in aggregate to determine whether
+required features and functionality are present. HL7® FHIR® resources are
+validated with the Java validator using `tx.fhir.org` as the terminology server.
+
+## Running the Tests
+
+### Quick Start
+
+For Inferno to simulate a server that always returns approved responses, it needs
+only to know the bearer token that the client will send on requests, for which there are two options.
+
+1. If you want to choose your own bearer token, then
+    1. Select the "2. PAS Client Validation" test from the list on the left.
+    2. Click the '*Run All Tests*' button on the right.
+    3. In the "access_token" field, enter the bearer token that will be sent by the client under test (as part
+        of the Authorization header - Bearer: <provided value>).
+    4. Click the '*Submit*' button at the bottom of the dialog.
+2. If you want to use a client_id to obtain an access token, then
+    1. Click the '*Run All Tests*' button on the right.
+    2. Provide the client's registered id "client_id" field of the input (NOTE, Inferno doesn't support the
+        registration API, so this must be obtained from another system or configured manually).
+    3. Click the '*Submit*' button at the bottom of the dialog.
+    4. Make a token request that includes the specified client id to the
+        `<inferno host>/custom/davinci_pas_client_suite_v201/mock_auth/token` endpoint to get
+        an access token to use on the request of the requests.
+
+In either case, the tests will continue from that point, requesting the user to
+direct the client to make certain requests to demonstrate PAS client capabilities.
+
+Note: authentication options for these tests have not been finalized and are subject to change.
+
+### Complete Setup
+
+The *Quick Start* approach does not test pended or deny workflows. To test these, provide a
+json-encoded FHIR bundle in the "Claim pended response JSON" and "Claim deny response JSON" input field after
+clicking the '*Run All Tests*' button. These responses will be echoed back when a request
+is made during the corresponding test.
+
+### Postman-based Demo
+
+If you do not have a PAS client but would like to try the tests out, you can use
+[this postman collection](https://github.com/inferno-framework/davinci-pas-test-kit/blob/main/config/PAS%20Test%20Kit%20Client%20Test%20Demo.postman_collection.json)
+to make requests against Inferno. The following requests and example responses from that collection can be used.
+
+- Configuration
+- *Deny Response* example under the *Homecare Prior Authorization Request*: use as the value of the
+    "Claim denied response JSON" input field. NOTE: this contains a placeholder code `DENIEDCODE` for the
+    X12 code representing the denied status. Replace with the X12-specified code before providing to Inferno
+    to accurately replicate a denial workflow for the client under test.
+- *Pend Response* example under the *Medical Services Prior Authorization Request*: use as the value of the
+    "Claim pended response JSON" input field. NOTE: this contains a placeholder code `PENDEDCODE` for the
+    X12 code representing the pended status. Replace with the X12-specified code before providing to Inferno
+    to accurately replicate a pend workflow for the client under test.
+- Submissions
+- *mock token*: for submitting a client id to get back an access token to use on the rest of the tests. Set the
+    collection's access_token variable to the result.
+- *Referral Prior Authorization Request*: use for the "Approval" workflow test submission.
+- *Medical Services Prior Authorization Request*: use for the "Pended" workflow test submission.
+- *Medical Services Inquiry Request*: use for the "Pended" workflow test inquiry.
+
+No additional requests are present to submit as a part of the must support tests, so
+testers can simply click the link to indicate they are done submitting requests. Note
+that the requests within the Postman client are not expected to fully pass the tests as they
+do not contain all must support items.
+
+## Testing Limitations
+
+### Private X12 details
+
+HIPAA [requires](https://hl7.org/fhir/us/davinci-pas/STU2/regulations.html) electronic prior authorization
+processing to use the X12 278 standard. While recent CMS rule-making suggests that [this requirement
+will not be enforced in the future](https://www.cms.gov/newsroom/fact-sheets/cms-interoperability-and-prior-authorization-final-rule-cms-0057-f),
+the current PAS IG relies heavily on X12.  As the IG authors note at the
+top of the [IG home page](https://hl7.org/fhir/us/davinci-pas/STU2/index.html):
+
+> Note that this implementation guide is intended to support mapping between FHIR and X12 transactions. To respect
+> X12 intellectual property, all mapping and X12-specific terminology information will be solely published by X12
+> and made available in accordance with X12 rules - which may require membership and/or payment. Please see this
+> [Da Vinci External Reference page](https://confluence.hl7.org/display/DVP/Da+Vinci+Reference+to+External+Standards+and+Terminologies)
+> for details on how to get this mapping.
+>
+> There are many situationally required fields that are specified in the X12 TRN03 guide that do not have guidance
+> in this Implementation Guide. Implementers need to consult the X12 PAS guides to know the requirements for these
+> fields.
+>
+> Several of the profiles will require use of terminologies that are part of X12 which we anticipate being made
+> publicly available. At such time as this occurs, the implementation guide will be updated to bind to these as
+> external terminologies.
+
+The implications of this reliance on proprietary information that is not publicly available means that this test
+kit:
+
+- Cannot verify the correct usage of X12-based terminology: terminology requirements for all elements bound to X12
+value sets will not be validated.
+- Cannot verify the meaning of codes: validation that a given response conveys something specific, e.g., approval
+or pending, is not performed.
+- Cannot verify matching semantics on inquiries: no checking of the identity of the ClaimResponse returned for an
+inquiry, e.g., that it matches the input or the original request.
+
+These limitations may be removed in future versions of these tests. In the meantime, testers should consider these
+requirements to be verified through attestation and should not represent their systems to have passed these tests
+if these requirements are not met.
+
+### Underspecified Subscription Details
+
+The current PAS specification around subscriptions and notifications
+is not detailed enough to support testing. Notably,
+- There are no examples of what a notification payload looks like
+- There is no instruction on how to turn the notification payload into an inquiry
+
+Once these details have been clarified, validation of the notification workflows
+will be added to these tests.
+
+### Future Details
+
+The PAS IG places additional requirements on clients that are not currently tested by this test kit, including
+
+- Prior Authorization update workflows
+- Requests for additional information handled through the CDex framework
+- PDF, CDA, and JPG attachments
+- US Core profile support for supporting information
+- The ability to handle responses containing all PAS-defined profiles and must support elements
+- Most details requiring manual review of the client system, e.g., the requirement that clinicians can update
+details of the prior authorization request before submitting them
+
+These and any other requirements found in the PAS IG may be tested in future versions of these tests.

data/lib/davinci_pas_test_kit/docs/server_suite_description_v201.md

@@ -0,0 +1,150 @@
+The Da Vinci PAS Server Suite validates the conformance of server systems 
+to the STU 2 version of the HL7® FHIR® 
+[Da Vinci Prior Authorization Support Implementation Guide](https://hl7.org/fhir/us/davinci-pas/STU2/).
+
+## Scope
+
+These tests are a **DRAFT** intended to allow PAS server implementers to perform 
+preliminary checks of their servers against PAS IG requirements and [provide 
+feedback](https://github.com/inferno-framework/davinci-pas-test-kit/issues) 
+on the tests. Future versions of these tests may validate other 
+requirements and may change the test validation logic.
+
+## Test Methodology
+
+Inferno will simulate a client and make a series of prior authorization requests to the 
+server under test. Over the course of these requests, Inferno will seek to observe
+conformant handling of PAS requirements, including
+- The ability of the server to use PAS API interactions to communicate 
+    - Approval of a prior authorization request
+    - Denial of a prior authorization request
+    - Pending of a prior authorization request and a subsequent final decision
+    - Inability to process a prior authorization request
+- The ability of the server to handle the full scope of data required by PAS, including
+    - Ability to process prior auth requests and inquiries with all PAS profiles and all must support elements on those profiles
+    - Ability to return responses that demonstrate the use of all PAS profiles and all must support elements on those profiles
+
+Because the business logic that determines decisions and the elements populated in responses
+Is outside of the PAS specification and will vary between implementers, testers
+are required to provide the requests that Inferno will make to the server.
+
+All requests and responses will be checked for conformance to the PAS
+IG requirements individually and used in aggregate to determine whether
+required features and functionality are present. HL7® FHIR® resources are 
+validated with the Java validator using `tx.fhir.org` as the terminology server.
+
+These tests do not currently test the full scope of the IG. See the *Testing Limitations* section below 
+for more details about the current scope of the tests and the reasons that some details have been left out.
+
+## Running the Tests
+
+### Quick Start
+
+Execution of these tests require a significant amount of tester input in the
+form of requests that Inferno will make against the server under test.
+
+If you would like to try out the tests using examples from the IG against the
+[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 
+1. Selecting the *Prior Authorization Support Reference Implementation* option from the Preset dropdown in the upper left
+2. Clicking the *Run All Tests* button in the upper right
+3. Clicking the *Submit* button at the bottom of the input dialog
+
+You can run these tests using your own server by updating the "FHIR Server Endpoint URL" and "OAuth Credentials" inputs.
+
+Note that:
+- the inputs for these tests are not complete and systems are not expected to pass the tests based on them.
+- the public reference server has not been updated to reflect the STU2 version that these tests target,
+    so expect some additional failures when testing against it.
+
+## Test Configuration Details
+
+The details provided here supplement the documentation of individual fields in the input dialog
+that appears when initiating a test run.
+
+### Server identification
+
+Requests will be made to the `/Claim/$submit` and `/Claim/$inquire` endpoints under the url provided in the "FHIR Server Endpoint URL" field.
+
+### Authentication
+
+The PAS IG states that 
+
+> "PAS Servers **SHOULD** support server-server OAuth… In a future release of this guide, direction will limit the option to [require] server-server OAuth."
+
+The PAS test kit currently assumes that the handshake has already occurred and requires
+that a bearer token be provided in the “OAuth Credentials / Access Token” configuration
+field. Inferno will submit this token on all requests it makes to the server as a part of 
+executing the tests. A complete backend server authentication handshake may be supported
+in future versions of the test kit.
+
+### Payload
+
+All other inputs are for providing bundles for Inferno to submit as a part of the tests. To avoid placing
+requirements on the business logic, Inferno does not have standard requests to send as a part of the tests
+and instead relies on the tester to provide the requests that Inferno will make.
+
+For single-request fields (e.g., “PAS Submit Request Payload for Approval Response”), the input must be a json-encoded FHIR bundle.
+
+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).
+
+## Testing Limitations
+
+### Private X12 details
+
+HIPAA [requires](https://hl7.org/fhir/us/davinci-pas/STU2/regulations.html) electronic prior authorization
+processing to use the X12 278 standard. While recent CMS rule-making suggests that [this requirement
+will not be enforced in the future](https://www.cms.gov/newsroom/fact-sheets/cms-interoperability-and-prior-authorization-final-rule-cms-0057-f),
+the current PAS IG relies heavily on X12.  As the IG authors note at the
+top of the [IG home page](https://hl7.org/fhir/us/davinci-pas/STU2/):
+
+> Note that this implementation guide is intended to support mapping between FHIR and X12 transactions. To respect
+> X12 intellectual property, all mapping and X12-specific terminology information will be solely published by X12
+> and made available in accordance with X12 rules - which may require membership and/or payment. Please see this
+> [Da Vinci External Reference page](https://confluence.hl7.org/display/DVP/Da+Vinci+Reference+to+External+Standards+and+Terminologies) 
+> for details on how to get this mapping.
+>
+> There are many situationally required fields that are specified in the X12 TRN03 guide that do not have guidance
+> in this Implementation Guide. Implementers need to consult the X12 PAS guides to know the requirements for these
+> fields.
+>
+> Several of the profiles will require use of terminologies that are part of X12 which we anticipate being made
+> publicly available. At such time as this occurs, the implementation guide will be updated to bind to these as
+> external terminologies.
+
+The implications of this reliance on proprietary information that is not publicly available means that this test
+kit:
+
+- Cannot verify the correct usage of X12-based terminology: terminology requirements for all elements bound to X12
+    value sets will not be validated.
+- Cannot verify the meaning of codes: validation that a given response conveys something specific, e.g., approval
+    or pending, is not performed.
+- Cannot verify matching semantics on inquiries: no checking of the identity of the ClaimResponse returned for an
+    inquiry, e.g., that it matches the input or the original request.
+
+These limitations may be removed in future versions of these tests. In the meantime, testers should consider these
+requirements to be verified through attestation and should not represent their systems to have passed these tests
+if these requirements are not met.
+
+### Underspecified Subscription Details
+
+The current PAS specification around subscriptions and notifications
+is not detailed enough to support testing. Notably, 
+- There are no examples of what a notification payload looks like
+- There is no instruction on how to turn the notification payload into an inquiry
+
+Once these details have been clarified, validation of the notification workflows
+will be added to these tests.
+
+### Future Details
+
+The PAS IG places additional requirements on servers that are not currently tested by this test kit, including
+
+- Prior Authorization update workflows
+- Requests for additional information handled through the CDex framework
+- PDF, CDA, and JPG attachments
+- US Core profile support for supporting information
+- Inquiry matching and subsetting logic
+- Inquiry requests from non-submitting systems
+- Collection of metrics
+
+These and any other requirements found in the PAS IG may be tested in future versions of these tests.