davinci_dtr_test_kit 0.12.0 → 0.14.0

data/lib/davinci_dtr_test_kit/docs/dtr_payer_server_suite_description_v201.md

@@ -13,20 +13,20 @@ requirements and may change the test validation logic.
 ## Test Methodology
 
 Inferno will simulate a DTR client application (SMART client or Full EHR) that
-is making requests for questionnaires for the server under test to interact with. 
+is making requests for questionnaires for the server under test to interact with.
 The server will be expected to respond to these requests made by Inferno. Over the
-course of these interactions, Inferno will seek to observe conformant handling of 
-DTR [requirements](https://hl7.org/fhir/us/davinci-dtr/STU2/specification.html#defining-questionnaires) 
-around standard questionnaires, adaptive questionnaires, or both. 
+course of these interactions, Inferno will seek to observe conformant handling of
+DTR [requirements](https://hl7.org/fhir/us/davinci-dtr/STU2/specification.html#defining-questionnaires)
+around standard questionnaires, adaptive questionnaires, or both.
 
 In terms of the validation performed on the returned questionnaires these
 tests assume that payers are not required to support specific features, but only those
-that they need in order to implement their forms. The DTR IG does [require that](https://hl7.org/fhir/us/davinci-dtr/STU2/specification.html#population) 
+that they need in order to implement their forms. The DTR IG does [require that](https://hl7.org/fhir/us/davinci-dtr/STU2/specification.html#population)
 "Questionnaires SHALL include logic that supports population from the EHR where possible"
 and puts some restrictions on how Questionnaire features can be used. Thus, these
 tests require demonstration of pre-population features and validates conformant
 use of Questionnaire features, but don't currently require demonstration of all
-Questionnnaire Must Support elements.
+Questionnaire Must Support elements.
 
 Because the business logic that determines which questionnaires are returned
 is outside of the DTR specification and will vary between implementers, testers
@@ -34,7 +34,7 @@ are required to provide the requests that Inferno will make to the server, eithe
 by providing the requests to make up-front, or by sending them to Inferno during
 test execution using a tester-controlled client.
 
-All responses returned by the server, as well as tester-provided requests, will be checked 
+All responses returned by the server, as well as tester-provided requests, will be checked
 for conformance to the DTR 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.
@@ -46,33 +46,35 @@ validated with the Java validator using `tx.fhir.org` as the terminology server.
 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 don't have a server or know specific requests that will elicit representative
-questionnaires from your server, see the *Sample Execution* section below.
+questionnaires from your server, see the _Sample Execution_ section below.
 
 Otherwise, the requests for Inferno to make can be provided in one of two ways:
-1. Statically within the Inferno inputs: provide the json request bodies when running
+
+1. **Statically within the Inferno inputs**: provide the json request bodies when running
    the tests. This approach works very well for testing standard (static) questionnaires
-   where there is only one request for Inferno to make (input = *Initial Static Questionnaire Request*). It is less ideal for adaptive
-   questionnaires as a sequence of `$next-question` requests (inputs = *Initial Adaptive Questionnaire Request* and *Next Question Requests*) is required, which is provided as a json list of
+   where there is only one request for Inferno to make (input = _Initial Static Questionnaire Request_). It is less ideal for adaptive
+   questionnaires as a sequence of `$next-question` requests (inputs = _Initial Adaptive Questionnaire Request_ and _Next Question Requests_) is required, which is provided as a json list of
    request body objects.
-2. Dynamically during test execution: use a tester-controlled client to provide requests to
+2. **Dynamically during test execution**: use a tester-controlled client to provide requests to
    Inferno while the tests are running. At points that Inferno needs to make a request, execution
    will pause while the request is provided from the client. Inferno uses a bearer token
-   provided in the test inputs (input = *Access Token* for the DTR Client Flow (not the
-   one under the *OAuth Credentials* input)) to identify these requests. The provided token 
+   provided in the test inputs (input = _Access Token_ for the DTR Client Flow (not the
+   one under the _OAuth Credentials_ input)) to identify these requests. The provided token
    must be sent as a part of the string `Bearer <token>` within the `Authentication` header of
-   all requests. When Inferno receives a request from the tester-controlled client, it will 
+   all requests. When Inferno receives a request from the tester-controlled client, it will
    send that to the server under test and then return the response back to the client so that
    the client's workflow, e.g., around an adaptive questionnaire can continue.
 
 In addition to the above configuration needed for identification of tests, the following additional
 inputs are required
-- *Questionnaire Retrieval Method*: indicate whether only static, only adaptive, or both types
+
+- _Questionnaire Retrieval Method_: indicate whether only static, only adaptive, or both types
   of questionnaires will be tested.
-- *FHIR Server Base Url*: the location of the server to test
-- *OAuth Credentials*: if the server under test requires authentication, provide those details
+- _FHIR Server Base Url_: the location of the server to test
+- _OAuth Credentials_: if the server under test requires authentication, provide those details
   here.
 
-For more details on additional inputs that may be needed, see the *Additional Configuration Details*
+For more details on additional inputs that may be needed, see the _Additional Configuration Details_
 section below.
 
 ### Sample Execution
@@ -80,22 +82,22 @@ section below.
 If you would like to try out the tests but don't have a DTR payer server implementation,
 you can run these tests against the DTR SMART Client test suite included in this test kit
 using the following steps:
+
 1. Start an Inferno session of the Da Vinci DTR SMART App Test Suite.
-1. Select test 1.1.1 *Retrieving the Static Questionnaire* from the menu on the left.
+1. Select test 1.1.1 _Retrieving the Static Questionnaire_ from the menu on the left.
 1. Click the "Run All Tests" button in the upper right.
 1. In the "SMART App Launch" select `Standalone Launch` and in the "client_id" input, put `sample`.
 1. Click the "submit" button in the dialog that appears. The client tests will now be waiting for requests.
 1. Start an Inferno session of the DTR Payer Server test suite.
-1. Select test 1 *Static Questionnaire Package Retrieval* from the menu on the left.
-1. Select the *Run Against DTR SMART App Tests* option from the Preset dropdown in the
+1. Select test 1 _Static Questionnaire Package Retrieval_ from the menu on the left.
+1. Select the _Run Against DTR SMART App Tests_ option from the Preset dropdown in the
    upper left.
 1. Click the "Run All Tests" button in the upper right.
 1. Click the "submit" button in the dialog that appears. The server tests will now make requests
-   against the client test session, which will respond with a static questionnaire that the 
+   against the client test session, which will respond with a static questionnaire that the
    these server tests can validate.
 
-At this time, only the standard questionnaire functionality can be tested using this approach as
-the client tests have not implemented an adaptive questionnaire set of tests.
+At this time, only the standard questionnaire functionality can be tested using this approach.
 
 ## Additional Configuration Details
 
@@ -104,7 +106,7 @@ that appears when initiating a test run.
 
 ### Custom Endpoint for Accessing a Particular Resource
 
-If the `$questionnaire-package` requests should be made to a location other than 
+If the `$questionnaire-package` requests should be made to a location other than
 `/Questionnaire/$questionnaire-package` under the base server URL, enter the
 location the requests should be made relative to the base server URL.
 
@@ -118,10 +120,11 @@ intention of the IG authors then future versions of the tests may require the pa
 to provide additional examples.
 
 The payer responses are also tested to ensure that appropriate libraries and expressions are
- included to faciliate pre-population of questionnaires. The following is not tested:
+included to facilitate pre-population of questionnaires. The following is not tested:
+
 - CQL is version 1.5
 - CQL is valid and executed to populate the questionnaire
 - CQL has a context of “Patient”
 - CQL definitions and variables defined on ancestor elements or preceding expression extensions within the same
-Questionnaire item are in scope for referencing in descendant/following expressions.
-- Within Expression elements, the base expression CQL SHALL be accompanied by a US Public Health Alternative Expression Extension containing the compiled JSON ELM for the expression.
+  Questionnaire item are in scope for referencing in descendant/following expressions.
+- Within Expression elements, the base expression CQL SHALL be accompanied by a US Public Health Alternative Expression Extension containing the compiled JSON ELM for the expression.

data/lib/davinci_dtr_test_kit/docs/dtr_smart_app_suite_description_v201.md

@@ -12,24 +12,27 @@ requirements and may change the test validation logic.
 
 ## Test Methodology
 
-Inferno will simulate a DTR payer server and light EHR that will response to
-requests for questionnaires and clinical data for the app under test to interact with. 
+Inferno will simulate a DTR payer server and light EHR that will respond to
+requests for questionnaires and clinical data for the app under test to interact with.
 The app will be expected to initiate requests to Inferno to elicit responses. Over the
-course of these interactions, Inferno will seek to observe conformant handling of 
+course of these interactions, Inferno will seek to observe conformant handling of
 DTR workflows and requirements around the retrieval, completion, and storage of
 questionnaires.
 
 Tests within this suite are associated with specific questionnaires that the app will
 demonstrate completion of. In each case, the app under test will initiate a request to
-the payer server simulated by Inferno for a questionnaire using the 
+the payer server simulated by Inferno for a questionnaire using the
 `$questionnaire-package` operation. Inferno will always return the specific questionnaire
 for the test being executed regardless of the input provided by the app, though it must
 be conformant. The app will then be asked to complete the questionnaire, including
+
 - Pre-populating answers based on directives in the questionnaire, which includes the
   fetching of associated data from the light EHR simulated by Inferno
 - Rendering the questionnaire for users and allowing them to make additional updates.
   These tests can include specific directions on details to include in the completed
   questionnaire.
+- For adaptive questionnaires only, getting additional questions using the `$next-question`
+  operation until the questionnaire is complete.
 - Storing the completed questionnaire back to the light EHR simulated by Inferno. Inferno
   will validate the stored questionnaire, including pre-populated values (Inferno knows
   the pre-population logic and the data used in calculation) and other conformance details.
@@ -37,13 +40,15 @@ be conformant. The app will then be asked to complete the questionnaire, includi
 Apps will be required to complete all questionnaires in the suite, which in aggregate
 contain all questionnaire features that apps must support. Currently, the suite includes
 two questionnaires:
-1. A fictious "dinner" questionnaire created for these tests. It tests basic
-   item rendering and pre-population.
-2. A Respiratory Assist Device questionnaire pulled from the DTR reference implementation.
+
+1. Standard and adaptive styles of a fictitious "dinner" questionnaire created for these tests. 
+   They test basic item rendering, control flow, and pre-population.
+1. A Respiratory Assist Device questionnaire pulled from the DTR reference implementation.
    It tests additional features and represents a more realistic questionnaire.
+
 Additional questionnaires will be added in the future.
 
-All requests sent by the app will be checked 
+All requests sent by the app will be checked
 for conformance to the DTR 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.
@@ -53,6 +58,7 @@ validated with the Java validator using `tx.fhir.org` as the terminology server.
 ### Quick Start
 
 This test suite can be run in two modes, each described below:
+
 1. [EHR launch mode](#ehr-launch)
 2. [Standalone launch mode](#standalone-launch)
 
@@ -64,7 +70,7 @@ The DTR specification allows apps and their partners significant leeway in terms
 what information is provided on launch and how that information gets used by the app
 to determine the `$questionnaire-package` endpoint and what details to submit as a
 part of that operation. Inferno cannot know ahead of time what data needs to be
-available for the app under test to successfully request, pre-populate, and render 
+available for the app under test to successfully request, pre-populate, and render
 a questionnaire. See the "`fhirContext` and available instances"
 section below for details on how to enable Inferno to meet the needs of your application.
 
@@ -72,28 +78,31 @@ section below for details on how to enable Inferno to meet the needs of your app
 
 In this mode Inferno will launch the app under test using the SMART App Launch
 [EHR launch](https://hl7.org/fhir/smart-app-launch/STU2.1/app-launch.html#launch-app-ehr-launch)
-flow. 
+flow.
 
 The tester must provide
+
 1. a `client_id`: can be any string and will uniquely identify the testing session.
 2. a `launch_uri`: will be used by Inferno to generate a link to launch the app under test.
 
 All the details needed to access clinical data from Inferno's simulated EHR are provided
-as a part of the SMART flow, including 
+as a part of the SMART flow, including
+
 - the FHIR base server URL to request data from
 - a bearer token to provide on all requests
 
 #### Standalone Launch
 
-In this mode the app under test will launch and on its own and reach out to Inferno to
-begin the workflow as described in the 
+In this mode the app under test will launch on its own and reach out to Inferno to
+begin the workflow as described in the
 [standalone launch section](https://hl7.org/fhir/smart-app-launch/STU2.1/app-launch.html#launch-app-standalone-launch).
 
 The tester must provide
+
 1. a `client_id`: can be any string and will uniquely identify the testing session.
 
 The app will then need to connect to Inferno as directed to initiate the SMART and DTR
-workflow. The FHIR base server url that app will connect to is 
+workflow. The FHIR base server url that app will connect to is
 `[URL prefix]/custom/dtr_smart_app/fhir` where `[URL prefix]` comes from the URL of the
 test session which will be of the form `[URL prefix]/dtr_smart_app/[session id]`
 
@@ -101,20 +110,25 @@ test session which will be of the form `[URL prefix]/dtr_smart_app/[session id]`
 
 If you do not have a DTR SMART app but would like to try the tests out, you can use
 [this Postman collection](https://github.com/inferno-framework/davinci-dtr-test-kit/blob/main/config/DTR%20SMART%20App%20Tests%20Postman%20Demo.postman_collection.json)
-to make requests against Inferno. This does not include the capability to render the complete the
+to make requests against Inferno. This does not include the capability to render the complete
 questionnaires, but does have samples of correctly and incorrectly completed QuestionnaireResponses.
 The following is a list of tests with the Postman requests that can be used with them:
 
-- **Standalone launch sequence**: use requests in the `SMART App Launch` folder during 
+- **Standalone launch sequence**: use requests in the `SMART App Launch` folder during
   tests **1.1.1.01** or **2.1.1.01** to simulate the SMART Launch flow and obtain an access
   token to use for subsequent requests. See the collection's Overview for details on the
   access token's generation.
-- **1.1** *Static Questionnaire Workflow*: use requests in the `Static Dinner` folder
-  - **1.1.1.01** *Invoke the DTR Questionnaire Package operation*: submit request `Questionnaire Package for Dinner (Static)` while this test is waiting.
-  - **1.1.3.01** *Save the QuestionnaireResponse after completing it*: submit request `Save QuestionnaireResponse for Dinner (Static)` while this test is waiting. If you want to see a failure, submit request `Save QuestionnaireResponse for Dinner (Static) - missing origin extension` instead.
-- **2.1** *Respiratory Assist Device Questionnaire Workflow*: use requests in the `Respiratory Assist Device` folder
-  - **2.1.1.01** *Invoke the DTR Questionnaire Package operation*: submit request `Questionnaire Package for Resp Assist Device` while this test is waiting.
-  - **2.1.3.01** *Save the QuestionnaireResponse after completing it*: submit request `Save Questionnaire Response for Resp Assist Device` while this test is waiting. If you want to see a failure, submit request `Save Questionnaire Response for Resp Assist Device - unexpected override` instead.
+- **1.1** _Static Questionnaire Workflow_: use requests in the `Static Dinner` folder
+  - **1.1.1.01** _Invoke the DTR Questionnaire Package operation_: submit request `Questionnaire Package for Dinner (Static)` while this test is waiting.
+  - **1.1.3.01** _Save the QuestionnaireResponse after completing it_: submit request `Save QuestionnaireResponse for Dinner (Static)` while this test is waiting. If you want to see a failure, submit request `Save QuestionnaireResponse for Dinner (Static) - missing origin extension` instead.
+- **1.2** _Adaptive Questionnaire Workflow_: use requests in the `Adaptive Dinner` folder
+  - **1.2.1.1.01** _Invoke the Questionnaire Package and Initial Next Question Operation_: submit requests `Questionnaire Package for Dinner` and then `Initial Next Question` while this test is waiting.
+  - **1.2.2.1.01** _Invoke the $next-question operation_: submit request `Second Next Question` while this test is waiting.
+  - **1.2.3.1.01** _Invoke the $next-question operation_: submit request `Final Next Question` while this test is waiting.
+  - **1.2.4.01** _Save the QuestionnaireResponse after completing it_: submit request `Save QuestionnaireResponse` while this test is waiting.
+- **2.1** _Respiratory Assist Device Questionnaire Workflow_: use requests in the `Respiratory Assist Device` folder
+  - **2.1.1.01** _Invoke the DTR Questionnaire Package operation_: submit request `Questionnaire Package for Resp Assist Device` while this test is waiting.
+  - **2.1.3.01** _Save the QuestionnaireResponse after completing it_: submit request `Save Questionnaire Response for Resp Assist Device` while this test is waiting. If you want to see a failure, submit request `Save Questionnaire Response for Resp Assist Device - unexpected override` instead.
 
 ## Configuration Details
 
@@ -135,24 +149,26 @@ controlled by the following inputs present on each group associated with a quest
 
 - **SMART App Launch Patient ID**: provide an `id` for the subject Patient FHIR instance.
 - **SMART App Launch `fhirContext`**: provide a JSON object containing FHIR references to instances
-  relevant to the DTR workflow, e.g. 
-  
+  relevant to the DTR workflow, e.g.
+
   ```
   [{reference: 'Coverage/cov015'}, {reference: 'DeviceRequest/devreqe0470'}]
-  ``` 
+  ```
+
   This will be included under the `fhirContext` key of the token response.
+
 - **EHR-available resources**: provide a Bundle containing FHIR instances referenced in and from the
   previous two inputs. Each instance must include an `id` element that Inferno will use in conjunction
   with the `resourceType` to make the instances available at the `[server base url]/[resourceType]/[id]`.
 
 Each questionnaire workflow group description includes a link to the questionnaire package that Inferno will return
 (e.g., [here](https://github.com/inferno-framework/davinci-dtr-test-kit/blob/main/lib/davinci_dtr_test_kit/fixtures/dinner_static/questionnaire_dinner_order_static.json))
-where you can find `id` and `url` values and any other details needed to determine what inputs 
+where you can find `id` and `url` values and any other details needed to determine what inputs
 will allow the app under test to work with that questionnaire. Note additionally that Inferno will always
 return that questionnaire in response to `$questionnaire-package` requests made during that test.
 
 These inputs can be cumbersome to create and if you have suggestions about how to improve this process
-while keeping the flexibility of Inferno to run with any app, submit a ticket 
+while keeping the flexibility of Inferno to run with any app, submit a ticket
 [here](https://github.com/inferno-framework/davinci-pas-test-kit/issues).
 
 ## Limitations
@@ -163,9 +179,9 @@ features. A few specific features of interest are listed below.
 
 ### Launching and security
 
-This test kit contains basic SMART App Launch cabilities that may not be complete. In particular,
-refresh tokens are not currently supported and scopes are not precise. To provide feedback and 
-input on the design of this feature and help us priortize improvements, submit a ticket 
+This test kit contains basic SMART App Launch capabilities that may not be complete. In particular,
+refresh tokens are not currently supported and scopes are not precise. To provide feedback and
+input on the design of this feature and help us prioritize improvements, submit a ticket
 [here](https://github.com/inferno-framework/davinci-pas-test-kit/issues).
 
 ### Combined payer and EHR FHIR servers
@@ -178,5 +194,5 @@ to retrieve questionnaires.
 ### Questionnaire Feature Coverage
 
 Not all questionnaire features that are must support within the DTR IG are currently represented
-in questionnaires tested by the IG. Adaptive questionnaires are a notable omission.
-Additional questionnaires testing additional features will be added in the future.
+in questionnaires tested by the IG. Additional questionnaires testing additional features will
+be added in the future.

data/lib/davinci_dtr_test_kit/dtr_full_ehr_suite.rb

@@ -1,15 +1,15 @@
-require_relative 'ext/inferno_core/runnable'
-require_relative 'ext/inferno_core/record_response_route'
-require_relative 'ext/inferno_core/request'
 require_relative 'client_groups/dinner_static/dtr_full_ehr_questionnaire_workflow_group'
+require_relative 'client_groups/dinner_adaptive/dtr_full_ehr_adaptive_dinner_questionnaire_workflow_group'
 require_relative 'auth_groups/oauth2_authentication_group'
-require_relative 'mock_payer'
+require_relative 'endpoints/cors'
+require_relative 'endpoints/mock_authorization/simple_token_endpoint'
+require_relative 'endpoints/mock_payer/full_ehr_questionnaire_package_endpoint'
+require_relative 'endpoints/mock_payer/full_ehr_next_question_endpoint'
 require_relative 'version'
 
 module DaVinciDTRTestKit
   class DTRFullEHRSuite < Inferno::TestSuite
-    extend MockPayer
-    extend MockAuthServer
+    extend CORS
 
     id :dtr_full_ehr
     title 'Da Vinci DTR Full EHR Test Suite'
@@ -45,27 +45,23 @@ module DaVinciDTRTestKit
       end
     end
 
-    allow_cors QUESTIONNAIRE_PACKAGE_PATH
+    allow_cors QUESTIONNAIRE_PACKAGE_PATH, NEXT_PATH
 
-    record_response_route :post, PAYER_TOKEN_PATH, 'dtr_full_ehr_payer_token',
-                          method(:payer_token_response) do |request|
-      DTRFullEHRSuite.extract_client_id_from_form_params(request)
-    end
+    suite_endpoint :post, PAYER_TOKEN_PATH, MockAuthorization::SimpleTokenEndpoint
 
-    record_response_route :post, QUESTIONNAIRE_PACKAGE_PATH, QUESTIONNAIRE_PACKAGE_TAG,
-                          method(:questionnaire_package_response) do |request|
-      DTRFullEHRSuite.extract_bearer_token(request)
-    end
+    suite_endpoint :post, QUESTIONNAIRE_PACKAGE_PATH, MockPayer::FullEHRQuestionnairePackageEndpoint
+    suite_endpoint :post, NEXT_PATH, MockPayer::FullEHRNextQuestionEndpoint
 
     resume_test_route :get, RESUME_PASS_PATH do |request|
-      DTRFullEHRSuite.extract_token_from_query_params(request)
+      request.query_parameters['token']
     end
 
     resume_test_route :get, RESUME_FAIL_PATH, result: 'fail' do |request|
-      DTRFullEHRSuite.extract_token_from_query_params(request)
+      request.query_parameters['token']
     end
 
     group from: :oauth2_authentication
     group from: :dtr_full_ehr_static_dinner_questionnaire_workflow
+    group from: :dtr_full_ehr_adaptive_dinner_questionnaire_workflow
   end
 end

data/lib/davinci_dtr_test_kit/dtr_light_ehr_suite.rb

@@ -1,18 +1,25 @@
+require 'us_core_test_kit'
+require 'tls_test_kit'
 require_relative 'version'
+require_relative 'dtr_options'
+require_relative 'profiles/questionnaire_response_group'
+require_relative 'profiles/coverage_group'
+require_relative 'profiles/communication_request_group'
+require_relative 'profiles/device_request_group'
+require_relative 'profiles/encounter_group'
+require_relative 'profiles/medication_request_group'
+require_relative 'profiles/nutrition_order_group'
+require_relative 'profiles/service_request_group'
+require_relative 'profiles/task_group'
+require_relative 'profiles/vision_prescription_group'
+require 'smart_app_launch/smart_stu1_suite'
+require 'smart_app_launch/smart_stu2_suite'
 
 module DaVinciDTRTestKit
   class DTRLightEHRSuite < Inferno::TestSuite
     id :dtr_light_ehr
     title 'Da Vinci DTR Light EHR Test Suite'
-    description %(
-        # Da Vinci DTR Light EHR Test Suite
-
-        This suite validates that an EMR or other application
-        can act as a data source for a DTR SMART App. Inferno
-        will act as a DTR SMART App making requests for data
-        against the system under test and storing completed
-        questionnaire responses.
-      )
+    description File.read(File.join(__dir__, 'docs', 'dtr_light_ehr_suite_description_v201.md'))
 
     version VERSION
 
@@ -35,28 +42,99 @@ module DaVinciDTRTestKit
       }
     ]
 
-    # These inputs will be available to all tests in this suite
     input :url,
-          title: 'FHIR Server Base Url'
-
-    input :credentials,
-          title: 'OAuth Credentials',
-          type: :oauth_credentials,
-          optional: true
-
-    # All FHIR requests in this suite will use this FHIR client
-    fhir_client do
-      url :url
-      oauth_credentials :credentials
-    end
+          title: 'FHIR Server Base Url',
+          description: 'URL of the target DTR Light EHR'
 
     # Hl7 Validator Wrapper:
     fhir_resource_validator do
-      igs 'hl7.fhir.us.davinci-dtr#2.0.1'
+      igs('hl7.fhir.us.davinci-dtr#2.0.1', 'hl7.fhir.us.davinci-pas#2.0.1', 'hl7.fhir.us.davinci-crd#2.0.1')
 
       exclude_message do |message|
         message.message.match?(/\A\S+: \S+: URL value '.*' does not resolve/)
       end
     end
+
+    group do
+      title 'Authorization'
+
+      group from: :smart_discovery_stu2 do
+        required_suite_options DTROptions::SMART_2_REQUIREMENT
+        run_as_group
+
+        test from: :tls_version_test do
+          title 'DTR FHIR Server is secured by transport layer security'
+          description <<~DESCRIPTION
+            Under [Privacy, Security, and Safety](https://hl7.org/fhir/us/davinci-crd/STU2/security.html),
+            the DTR Implementation Guide imposes the following rule about TLS:
+            As per the [DTR Hook specification](https://cds-hooks.hl7.org/2.0/#security-and-safety),
+            communications between DTR Clients and DTR Servers SHALL
+            use TLS. Mutual TLS is not required by this specification but is permitted. DTR Servers and
+            DTR Clients SHOULD enforce a minimum version and other TLS configuration requirements based
+            on HRex rules for PHI exchange.
+            This test verifies that the FHIR server is using TLS 1.2 or higher.
+          DESCRIPTION
+
+          id :dtr_server_tls_version_stu2
+
+          config(
+            options: { minimum_allowed_version: OpenSSL::SSL::TLS1_2_VERSION }
+          )
+        end
+      end
+
+      group from: :smart_ehr_launch_stu2,
+            required_suite_options: DTROptions::SMART_2_REQUIREMENT,
+            run_as_group: true
+
+      group from: :smart_standalone_launch_stu2,
+            required_suite_options: DTROptions::SMART_2_REQUIREMENT,
+            run_as_group: true
+    end
+
+    group do
+      title 'FHIR API'
+      description %(This test group tests systems for their conformance to
+      the US Core v3.1.1 Capability Statement as defined by the DaVinci Documentation
+      Templates and Rules (DTR) v2.0.1 Implementation Guide Light DTR EHR
+      Capability Statement.
+
+      )
+
+      group from: :'us_core_v311-us_core_v311_fhir_api',
+            run_as_group: true
+    end
+
+    group do
+      title 'DTR Light EHR Profiles'
+      description %(This test group tests system for their conformance to
+      the RESTful capabilities by specified Resources/Profiles as defined by
+      the DaVinci Documentation Templates and Rules (DTR) v2.0,1 Implementation
+      Guide Light DTR EHR Capability Statement.
+
+      )
+
+      input :credentials,
+            title: 'OAuth Credentials',
+            type: :oauth_credentials,
+            optional: true
+
+      # All FHIR requests in this suite will use this FHIR client
+      fhir_client do
+        url :url
+        oauth_credentials :credentials
+      end
+
+      group from: :questionnaire_response_group
+      group from: :coverage_group
+      group from: :communication_request_group
+      group from: :device_request_group
+      group from: :encounter_group
+      group from: :medication_request_group
+      group from: :nutrition_order_group
+      group from: :service_request_group
+      group from: :task_group
+      group from: :vision_prescription_group
+    end
   end
 end

data/lib/davinci_dtr_test_kit/dtr_options.rb

@@ -0,0 +1,7 @@
+module DaVinciDTRTestKit
+  module DTROptions
+    SMART_2 = 'smart_app_launch_2'.freeze
+
+    SMART_2_REQUIREMENT = { smart_app_launch_version: SMART_2 }.freeze
+  end
+end

data/lib/davinci_dtr_test_kit/dtr_payer_server_suite.rb

@@ -1,17 +1,15 @@
-require_relative 'ext/inferno_core/runnable'
-require_relative 'ext/inferno_core/record_response_route'
-require_relative 'ext/inferno_core/request'
 require_relative 'payer_server_groups/payer_server_static_group'
 require_relative 'payer_server_groups/payer_server_adaptive_group'
 require_relative 'tags'
-require_relative 'mock_payer'
-require_relative 'mock_auth_server'
+require_relative 'endpoints/cors'
+require_relative 'endpoints/mock_authorization/simple_token_endpoint'
+require_relative 'endpoints/mock_payer/questionnaire_package_proxy_endpoint'
+require_relative 'endpoints/mock_payer/next_question_proxy_endpoint'
 require_relative 'version'
 
 module DaVinciDTRTestKit
   class DTRPayerServerSuite < Inferno::TestSuite
-    extend MockAuthServer
-    extend MockPayer
+    extend CORS
 
     id :dtr_payer_server
     title 'Da Vinci DTR Payer Server Test Suite'
@@ -106,22 +104,13 @@ module DaVinciDTRTestKit
 
     allow_cors QUESTIONNAIRE_PACKAGE_PATH, NEXT_PATH
 
-    record_response_route :post, PAYER_TOKEN_PATH, 'dtr_payer_auth', method(:payer_token_response) do |request|
-      DTRPayerServerSuite.extract_client_id_from_form_params(request)
-    end
-
-    record_response_route :post, QUESTIONNAIRE_PACKAGE_PATH, QUESTIONNAIRE_TAG,
-                          method(:payer_questionnaire_response), resumes: method(:test_resumes?) do |request|
-      DTRPayerServerSuite.extract_bearer_token(request)
-    end
+    suite_endpoint :post, PAYER_TOKEN_PATH, MockAuthorization::SimpleTokenEndpoint
 
-    record_response_route :post, NEXT_PATH, NEXT_TAG,
-                          method(:questionnaire_next_response), resumes: method(:test_resumes?) do |request|
-      DTRPayerServerSuite.extract_bearer_token(request)
-    end
+    suite_endpoint :post, QUESTIONNAIRE_PACKAGE_PATH, MockPayer::QuestionnairePackageProxyEndpoint
+    suite_endpoint :post, NEXT_PATH, MockPayer::NextQuestionProxyEndpoint
 
     resume_test_route :get, RESUME_PASS_PATH do |request|
-      DTRPayerServerSuite.extract_token_from_query_params(request)
+      request.query_parameters['token']
     end
 
     group from: :payer_server_static_package