davinci_pas_test_kit 0.12.0 → 0.12.1

data/lib/davinci_pas_test_kit/docs/client_suite_description_v201.md

@@ -16,27 +16,23 @@ Inferno will simulate a PAS server for the client under test to interact with. T
 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 initiate a prior authorization submission and react to
+    - The approval of the request
+    - The denial of the request
+    - The pending of the request and a subsequent notification that a final decision was made
 - 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.
+Inferno contains basic logic to generate approval, denial, and pended responses, along with a
+notification that a final decision was made, as a part of the above workflows.
+These responses are based on examples available in the PAS Implementation Guide
+and are conformant, but may not meet the needs of actual implementations. Thus,
+testers may provide Inferno with specific responses for Inferno to echo. If responses
+are provided, Inferno will check them for conformance to ensure that they demonstrate
+a fully conformant exchange.
 
 All requests and responses will be checked for conformance to the PAS
 IG requirements individually and used in aggregate to determine whether
@@ -47,67 +43,204 @@ validated with the Java validator using `tx.fhir.org` as the terminology server.
 
 ### Quick Start
 
-For Inferno to simulate a server that always returns approved responses, it needs
+For Inferno to simulate a server that returns mocked conformant 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.
+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>).
+    3. In the "Access Token" input field, enter the bearer token that will be sent by the client under test
+       in the Authorization HTTP header (format: `Bearer <provided value>`) for all requests to Inferno.
     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
+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
+    2. Provide the client's registered id "Client ID" input field (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
+    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 from Inferno which the client will need to provide in the 
+       Authorization HTTP header (format: `Bearer <provided value>`) for all subsequent 
+       requests to Inferno for this test session. See the documentation in the 
+       **1.** Demonstration Authorization test for details on the supported access token request.
+
+In either case, the tests will continue from that point, requesting the tester 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.
-
-Selecting the *Example PAS Server Responses* Preset in the dropdown in the upper left will fill in example
-FHIR bundles for the pended and deny responses. It will also fill in a sample value for the Client ID,
-which is only necessary for the *Demonstrate Authorization* test group, which can be skipped in favor of
-manual bearer token input in subsequent tests as described above.
-
 ### 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.
+to make requests against Inferno and see the mocked responses provided by Inferno. To use, load
+the collection into the [Postman app](https://www.postman.com/downloads/) and follow these steps:
+
+1. Select the *PAS Client Test Suite Demo* Collection in postman and go to the "Variables" tab 
+   (see the Overview tab for more details on what the variables control).
+1. Note the "Current value" of the **client_id** variable for use in configuring Inferno. Update it
+   to another value to use instead, if desired.
+1. Start a Da Vinci PAS Client Suite v2.0.1 session from the [PAS Test Kit page on 
+   inferno.healthit.gov](https://inferno.healthit.gov/test-kits/davinci-pas/). 
+1. Click the *Run All Tests* button in the upper right hand corner of the suite.
+1. In the **Client ID** input, enter the value from the **client_id** Postman variable and click the 
+   *Submit* button.
+1. When the "User Action" dialog appears, return to Postman and change to the Authorization tab. Scroll down 
+   to find the *Get New Access Token* button at the bottom and click it.
+1. When a success message appears, click the *Proceed* button and then the *Use Token* button.
+1. Back in Inferno, a new "User Action" dialog will appear requesting a Subscription. When it does, return to Postman,
+   open the "Create Subscription Request" entry under the "Subscription Setup" folder in the collection,
+   and click the *Send* button.
+1. Back in Inferno, an **Approval Workflow Test** "User Action" will appear. When it does, return to Postman,
+   open the "Prior Auth Request For Approval" entry under the "Approval Workflow Requests" folder in the
+   collection, and click the *Send* button.
+1. Back in Inferno, an attestation "User Action" will appear asking you to confirm that the prior auth
+   request is listed as approved in the client app based on Inferno's response to the request. Search
+   in the response returned to Postman for the string "Certified in total" which indicates the prior
+   auth request was approved and click the link in Inferno indicating the attestation statement is true.
+1. Next, a **Denial Workflow Test** "User Action" will appear. When it does, return to Postman,
+   open the "Prior Auth Request For Denial" entry under the "Denial Workflow Requests" folder in the
+   collection, and click the *Send* button.
+1. Back in Inferno, an attestation "User Action" will appear asking you to confirm that the prior auth
+   request is listed as denied in the client app based on Inferno's response to the request. Search
+   in the response returned to Postman for the string "Not Certified" which indicates the prior
+   auth request was denied and click the link in Inferno indicating the attestation statement is true.
+1. Next, a **Pended Workflow Test** "User Action" will appear. When it does, return to Postman,
+   open the "Prior Auth Request For Pended" entry under the "Pended Workflow Requests" folder in the
+   collection, and click the *Send* button.
+1. Search in the response returned to Postman for the string "Pending" which indicates the prior
+   auth request was pended and a final decision will be made later. You'll use this information in
+   a later attestation.
+1. Meanwhile, Inferno sent a notification indicating that a final decision was made (5-10 seconds
+   after the prior auth request). If interested in seeing the notification message, it can be found
+   on the [notifications 
+   page](https://subscriptions.argo.run/subscriptions/notifications-received?store=r4) for the 
+   [Argonaut Subscriptions Reference Implementation](https://subscriptions.argo.run/), which
+   hosts a notification endpoint that is used to receive Subscription notifications for this demo.
+   Note that when looking for recent notifications, **Received** timestamps are in UTC which is
+   5 hours ahead of Eastern Standard Time (4 hours ahead of Eastern Daylight Time).
+1. Return to Postman, open the "Prior Auth Inquiry For Pended" entry under the "Pended Workflow Requests"
+   folder in the collection, and click the *Send* button.
+1. Search in the response returned to Postman for the string "Certified in total" which indicates the prior
+   auth request was approved. You'll use this information in a later attestation.
+1. Return to Inferno, scroll down in the "User Action" dialog and click the "click here to complete the test"
+   link to allow Inferno to evaluate the pended workflow.
+1. Two attestations will appear, the first stating that the prior auth request was registered in the
+   client as pended and that it was subsequently finalized. You checked these above and can use the
+   true link for both.
+1. Two additional "User Action" dialogs will appear requesting additional `$submit` and `$inquire`
+   requests to demonstrate must support elements. This demo does not have any additional requests
+   and does not attempt to demonstrate all must support elements, so click the link to indicate
+   you are done submitting requests for each. Note that requests submitted during the workflow section
+   will be evaluated and you can inspect the results under test **3.2** *Demonstrate Element Support*
+   to see both passing and failing tests.
+1. Once Inferno finishes evaluating the requests, the test will complete allowing you to review the
+   results, including warning and error messages as well as requests associated with each test.
+
+#### Optional Demo Modifications
+
+This demo uses `id-only` notifications for Pended workflow. To see a demonstration of `full-resource`
+notifications, replace the string `id-only` in the "Create Subscription Request" entry under the 
+"Subscription Setup" folder in the collection with the string `full-resource` (found in an extension
+under the `_payload` element).
+
+## Response and Notification Content
+
+To assist in testers getting started with the PAS Client tests quickly, Inferno will generate
+conformant mocked `$submit` and `$inquire` operation responses and Subscription notifications.
+However, the simple mocked messages may not drive the workflows of real systems in a way that allows
+them to demonstrate their implementation of the PAS specification. Thus, Inferno also allows each message
+returned or initiated by Inferno to be specified by the tester. These messages must themselves be
+conformant to PAS specification requirements and additional test requirements in order for a test run to
+serve as a demonstration of a conformant implementation.
+
+The rest of this section provides details on how Inferno determines the content to use in responses
+and notifications.
+
+### Inferno Modifications of Tester-provided Responses and Notifications
+
+Requests provided by testers will be modified by Inferno to try and populate details that testers won't
+know ahead of time. These modifications fall into two categories:
+- **Timestamps**: creation timestamps, such as those on Bundles, ClaimResponses, and event notifications,
+  will be updated or populated by Inferno so that they are in sync with the time the message is sent.
+- **Resource Ids**: some resource ids will not be known ahead of time and will be added or updated by Inferno 
+  including
+  - *Claim Id*: if the tester provides a `$submit` or `$inquire` response with `ClaimResponse.request` populated,
+    then Inferno will update it with the fullUrl of the Claim provided in the request. This avoids the need for 
+    testers to know the Claim Id ahead of time which may be difficult for some systems.
+  - *ClaimResponse Id*: if the tester provides a Notification but has Inferno generate the `$submit` response,
+    then Inferno will update the focus to use the ClaimResponse id that it generates.
+
+If the tester provides an input that is malformed in some way such that Inferno cannot get the details
+that Inferno needs to make the modifications, then the raw input will be used.
+
+### Response and Notification Correspondence Requirements
+
+Beyond the minor modifications described above, Inferno does not modify provided content to ensure that
+they are consistent with each other or the time they are executed. For example, in the pended
+workflow, it is up to the tester to ensure that if they provide responses for the `$submit` and `$inquire`
+operations that they share whatever details, such as identifiers, needed to connect them together and drive
+the workflow in their system. Timestamps not associated with messaging time such as when a prior authorization
+response is valid are also not modified by Inferno. Unlike details that Inferno modifies as described above,
+testers should have control over and/or knowledge of the necessary details and values to construct consistent
+and working messages for Inferno to use.
+
+### Tester-provided Response and Notification Inputs
+
+The following test inputs control Inferno messaging behavior:
+- **Claim approved response JSON**: If populated, this is used in the **2.2.1** "Demonstrate Approval Workflow" tests
+  to respond to `$submit` requests. The response needs to indicate to the system that the prior auth request has
+  been approved.
+- **Claim denied response JSON**: If populated, this used in the **2.2.2** "Demonstrate Denial Workflow" tests
+  to respond to `$submit` requests. The response needs to indicate to the system that the prior auth request has
+  been denied.
+- **Claim pended response JSON**: If populated, this used in the **2.2.3** "Demonstrate Pended Workflow" tests
+  to respond to `$submit` requests. The response needs to indicate to the system that the prior auth request has
+  been pended.
+- **Claim updated notification JSON**: If populated, this used in the **2.2.3** "Demonstrate Pended Workflow" tests
+  as the event notification sent for the Subscription indicating that a decision has been finalized for the
+  pended prior auth request. The content of the notification needs to match the details of the Subscription
+  provided in the **2.1** "Subscription Setup" tests.
+- **Inquire approved response JSON**: If populated, this used in the **2.2.3** "Demonstrate Pended Workflow"
+  tests to respond to `$inquire` requests. The response needs to indicate to the system that the
+  prior auth request has been approved.
+
+### Generation Logic
+
+When generating responses and notifications, Inferno uses the following logic. These conform to the
+requirements of the PAS specification, but may not make sense in an actual workflow.
+- **`$submit` and `$inquire` responses**: these responses are created mostly from the incoming request, specific details include:
+  - The Patient, insurer Organization, and requestor entity instances are pulled into the response
+    Bundle and referenced in the `patient`, `insurer`, and `requestor` elements respectively.
+    Note that get found by following references found in the submitted Claim instance. If relative
+    references are used in the Claim, the Claim entry `fullUrl` needs to be a absolute reference
+    and not a UUID, else the entries won't get pulled in correctly.
+  - In the ClaimResponse, the `identifier`, `type`, `status`, and `use` elements are pulled
+    in from the Claim in the request.
+  - The `Bundle.timestamp` and `ClaimResponse.created` timestamps are populated using the current time.
+  - The `ClaimResponse.outcome` is hardcoded to `complete`.
+  - For each `item` entry in the request Claim, a `ClaimResponse.item` entry is created with the
+    `itemSequence` value copied over, `itemPreAuthIssueDate` and `itemPreAuthPeriod` extensions 
+    added using the current date and a month starting on the current date respectively,
+    and an adjudication entry with a `category` of `submitted` that contains the `reviewAction` extension with a
+    `reviewActionCode` that matches the current workflow: `A1` ("Certified in total") for approval,
+    `A3` ("Not Certified") for denial, and `A4` ("Pending") for pending.
+- **Notification Bundle**: Inferno supports mocking both `id-only` and `full-resource` notifications.
+  The following details are relevant:
+  - Inferno pulls in details from the Subscription created for the test session to use in
+   creating the Notification, including the `topic` and the `subscription` reference.
+  - Inferno hardcodes the `status` as `active` and the `type` as `event-notification`.
+  - Inferno will always include a single `notification-event` entry with a `timestamp` of the current
+    time and with a `focus` that points to the ClaimResponse returned on the `$submit`.
+    If it cannot find the ClaimResponse reference from the `$submit` response returned
+    by Inferno, it will generate a random UUID (which isn't likely to work correctly when received).
+  - The subscription's `events-since-subscription-start` and the event's `event-number` will always
+    be 1 as Inferno is not able to track notifications across multiple sessions or runs.
+  - When generating a `full-resource` notification, Inferno will include `additional-context`
+    references for each entry in the `$submit` response Bundle other than the ClaimResponse
+    (which is already in the `focus`). Then it will include Notification Bundle entries for
+    each instance in the `$submit` response Bundle, including the ClaimResponse, with `reviewActionCode`
+    extensions updated to indicate approval using code `A1` ("Certified in total") for approval.
 
 ## Testing Limitations
 
@@ -136,26 +269,34 @@ top of the [IG home page](https://hl7.org/fhir/us/davinci-pas/STU2/index.html):
 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
+- *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
+- *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
+- *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
+### Subscription Details
+
+Subscription details in the PAS 2.0.1 specification are relatively underspecified and the
+[published 2.1.0 version of the 
+specification](https://hl7.org/fhir/us/davinci-pas/STU2.1/specification.html#subscription) 
+makes significant changes, including requiring `full-resource` and updating details such as
+the filter criteria.
 
-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
+Based on the immaturity of the 2.0.1 requirements around Subscriptions, these tests implement and check for
+the mechanics of Subscriptions and notifications, but do not look closely at the details. For example,
+`id-only` and `full-resource` are supported and the filter criteria format is not checked. Future versions
+of these tests may be more stringent.
 
-Once these details have been clarified, validation of the notification workflows
-will be added to these tests.
+Additionally, to test Subscriptions and pending workflows, a new Subscription must be created for each
+test session, which may require testers to re-initialize previously-created Subscriptions. Future versions
+of these tests may relax this requirement and feedback on whether this would reduce burden and how this
+might look are welcome.
 
 ### Future Details
 
@@ -167,7 +308,7 @@ The PAS IG places additional requirements on clients that are not currently test
 - 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
+  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/endpoints/claim_endpoint.rb

@@ -1,25 +1,54 @@
 require_relative '../user_input_response'
+require_relative '../response_generator'
+require_relative '../urls'
+require_relative '../jobs/send_pas_subscription_notification'
+require 'subscriptions_test_kit'
 
 module DaVinciPASTestKit
   class ClaimEndpoint < Inferno::DSL::SuiteEndpoint
+    include SubscriptionsTestKit::SubscriptionsR5BackportR4Client::SubscriptionSimulationUtils
+    include ResponseGenerator
+    include URLs
+
+    # override the one from URLs
+    def suite_id
+      request.path.split('/custom/')[1].split('/')[0] # request.path = {base inferno path}/custom/{suite_id}/...
+    end
+
     def test_run_identifier
       request.headers['authorization']&.delete_prefix('Bearer ')
     end
 
     def tags
-      [operation == 'submit' ? SUBMIT_TAG : INQUIRE_TAG]
+      operation_tag = operation == 'submit' ? SUBMIT_TAG : INQUIRE_TAG
+      workflow_tag = WORKFLOW_TAG_MAP[workflow]
+
+      return [operation_tag, workflow_tag] if workflow_tag.present?
+
+      [operation_tag]
+    end
+
+    def workflow
+      case test.id
+      when /.*pended.*/
+        :pended
+      when /.*denial.*/
+        :denial
+      when /.*approval.*/
+        :approval
+      end
     end
 
+    WORKFLOW_TAG_MAP = {
+      pended: PENDED_WORKFLOW_TAG,
+      denial: DENIAL_WORKFLOW_TAG,
+      approval: APPROVAL_WORKFLOW_TAG
+    }.freeze
+
     def make_response
       response.status = 200
       response.format = :json
 
-      user_inputted_response = UserInputResponse.user_inputted_response(test, result)
-      if user_inputted_response.present?
-        response.body = user_inputted_response
-        return
-      end
-
       req_bundle = FHIR.from_contents(request.body.string)
       claim_entry = req_bundle&.entry&.find { |e| e&.resource&.resourceType == 'Claim' }
       claim_full_url = claim_entry&.fullUrl
@@ -28,27 +57,26 @@ module DaVinciPASTestKit
         return
       end
 
-      root_url = base_url(claim_full_url)
-      claim_response = mock_claim_response(claim_entry.resource, req_bundle, root_url)
-
-      res_bundle = FHIR::Bundle.new(
-        id: SecureRandom.uuid,
-        meta: FHIR::Meta.new(profile: if operation == 'submit'
-                                        'http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-pas-response-bundle'
-                                      else
-                                        'http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-pas-inquiry-response-bundle'
-                                      end),
-        timestamp: Time.now.utc.iso8601,
-        type: 'collection',
-        entry: [
-          FHIR::Bundle::Entry.new(fullUrl: "urn:uuid:#{claim_response.id}",
-                                  resource: claim_response)
-        ]
-      )
-
-      res_bundle.entry.concat(referenced_entities(claim_response, req_bundle.entry, root_url))
-
-      response.body = res_bundle.to_json
+      user_inputted_response = UserInputResponse.user_inputted_response(test, operation, result)
+      if user_inputted_response.present?
+        generated_claim_response_uuid = nil
+        response_bundle_json = update_tester_provided_response(user_inputted_response, claim_full_url)
+      else
+        decision = # always use the workflow, except for pended when the inquire will get approved
+          if operation == 'inquire' && workflow == :pended
+            :approval
+          else
+            workflow
+          end
+        generated_claim_response_uuid = SecureRandom.uuid
+        response_bundle_json = mock_response_bundle(req_bundle, operation, decision, generated_claim_response_uuid)
+      end
+
+      response.body = response_bundle_json
+
+      return unless workflow == :pended && operation == 'submit'
+
+      start_notification_job(response_bundle_json, :approval, generated_claim_response_uuid)
     end
 
     def update_result
@@ -57,78 +85,6 @@ module DaVinciPASTestKit
 
     private
 
-    # Note that references from the claim to other resources in the bundle need to be changed to absolute URLs
-    # if they are relative, because the ClaimResponse's fullUrl is a urn:uuid
-    #
-    # @private
-    def mock_claim_response(claim, bundle, root_url)
-      return FHIR::ClaimResponse.new(id: SecureRandom.uuid) if claim.blank?
-
-      now = Time.now.utc
-
-      FHIR::ClaimResponse.new(
-        id: SecureRandom.uuid,
-        meta: FHIR::Meta.new(profile: if operation == 'submit'
-                                        'http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claimresponse'
-                                      else
-                                        'http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claiminquiryresponse'
-                                      end),
-        identifier: claim.identifier,
-        type: claim.type,
-        status: claim.status,
-        use: claim.use,
-        patient: absolute_reference(claim.patient, bundle.entry, root_url),
-        created: now.iso8601,
-        insurer: absolute_reference(claim.insurer, bundle.entry, root_url),
-        requestor: absolute_reference(claim.provider, bundle.entry, root_url),
-        outcome: 'complete',
-        item: claim.item.map do |item|
-          FHIR::ClaimResponse::Item.new(
-            extension: [
-              FHIR::Extension.new(
-                url: 'http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-itemPreAuthIssueDate',
-                valueDate: now.strftime('%Y-%m-%d')
-              ),
-              FHIR::Extension.new(
-                url: 'http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-itemPreAuthPeriod',
-                valuePeriod: FHIR::Period.new(start: now.strftime('%Y-%m-%d'),
-                                              end: (now + 1.month).strftime('%Y-%m-%d'))
-              )
-            ],
-            itemSequence: item.sequence,
-            adjudication: [
-              FHIR::ClaimResponse::Item::Adjudication.new(
-                extension: [
-                  FHIR::Extension.new(
-                    url: 'http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-reviewAction',
-                    extension: [
-                      FHIR::Extension.new(
-                        url: 'http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-reviewActionCode',
-                        valueCodeableConcept: FHIR::CodeableConcept.new(
-                          coding: [
-                            FHIR::Coding.new(
-                              system: 'https://codesystem.x12.org/005010/306',
-                              code: 'A1',
-                              display: 'Certified in total'
-                            )
-                          ]
-                        )
-                      )
-                    ]
-                  )
-                ],
-                category: FHIR::CodeableConcept.new(
-                  coding: [
-                    FHIR::Coding.new(system: 'http://terminology.hl7.org/CodeSystem/adjudication', code: 'submitted')
-                  ]
-                )
-              )
-            ]
-          )
-        end
-      )
-    end
-
     def handle_missing_required_elements(claim_entry, response)
       response.status = 400
       details = if claim_entry.blank?
@@ -146,49 +102,44 @@ module DaVinciPASTestKit
       request.url&.split('$')&.last
     end
 
-    # Drop the last two segments of a URL, i.e. the resource type and ID of a FHIR resource
-    # e.g. http://example.org/fhir/Patient/123 -> http://example.org/fhir
-    # @private
-    def base_url(url)
-      return unless url&.start_with?('http://', 'https://')
+    def start_notification_job(response_bundle_json, decision, generated_claim_response_uuid)
+      notification_bearer_token = client_access_token_input(result)
+      notification_contents = notification_json(response_bundle_json, decision, generated_claim_response_uuid)
 
-      # Drop everything after the second to last '/', ignoring a trailing slash
-      url.sub(%r{/[^/]*/[^/]*(/)?\z}, '')
+      Inferno::Jobs.perform(Jobs::SendPASSubscriptionNotification, test_run.id, test_run.test_session_id, result.id,
+                            notification_bearer_token, notification_contents, test_run_identifier, suite_id)
     end
 
-    def referenced_entities(resource, entries, root_url)
-      matches = []
-      attributes = resource&.source_hash&.keys
-      attributes.each do |attr|
-        value = resource.send(attr.to_sym)
-        if value.is_a?(FHIR::Reference) && value.reference.present?
-          match = find_matching_entry(value.reference, entries, root_url)
-          if match.present? && matches.none?(match)
-            value.reference = match.fullUrl
-            matches.concat([match], referenced_entities(match.resource, entries, root_url))
-          end
-        elsif value.is_a?(Array) && value.all? { |elmt| elmt.is_a?(FHIR::Model) }
-          value.each { |val| matches.concat(referenced_entities(val, entries, root_url)) }
-        end
-      end
-
-      matches
-    end
+    def notification_json(response_bundle_json, decision, generated_claim_response_uuid)
+      user_inputted_notification_json =
+        JSON.parse(result.input_json).find { |i| i['name'] == 'notification_bundle' }['value']
 
-    def absolute_reference(ref, entries, root_url)
-      url = find_matching_entry(ref&.reference, entries, root_url)&.fullUrl
-      ref.reference = url if url
-      ref
+      if user_inputted_notification_json.present?
+        update_tester_provided_notification(user_inputted_notification_json, generated_claim_response_uuid)
+      else
+        generate_notification(response_bundle_json, decision)
+      end
     end
 
-    def find_matching_entry(ref, entries, root_url = '')
-      ref = "#{root_url}/#{ref}" if relative_reference?(ref) && root_url&.present?
+    def generate_notification(response_bundle_json, decision)
+      subscription = find_subscription(test_run.test_session_id, as_json: true)
+      subscription_reference = "#{fhir_subscription_url}/#{subscription['id']}"
+      subscription_topic = subscription['criteria']
 
-      entries&.find { |entry| entry&.fullUrl == ref }
+      if find_subscription_content_type(subscription) == 'full-resource'
+        mock_full_resource_notification_bundle(response_bundle_json, subscription_reference, subscription_topic,
+                                               decision)
+      else # assume id-only since empty not allowed - if asked for empty, other failures will occur
+        mock_id_only_notification_bundle(response_bundle_json, subscription_reference, subscription_topic)
+      end
     end
 
-    def relative_reference?(ref)
-      ref&.count('/') == 1
+    def find_subscription_content_type(subscription)
+      content_ext = subscription['channel']['_payload']['extension']
+        .find do |ext|
+          ext['url'] == 'http://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition/backport-payload-content'
+        end
+      content_ext['valueCode'] if content_ext.present?
     end
   end
 end