65.2.1Setup Prior Auth for Payers

This section describes the steps required for a payer to setup the Prior Authorization Solution within their Smile HDP environment.

65.2.1.1Overview

Payers primarily use the Prior Authorization Solution to manage their prior authorization workflows and expose relevant information to their in-network providers:

• Coverage Requirements Discovery (CRD): Payers configure CRD to expose clinical rules and coverage requirements, enabling providers to determine in advance whether prior authorization is needed and what information to submit. Providers access these rules by calling the CRD CDS Hooks REST endpoint (GET /cds-services) to retrieve the configured services.
• Documentation Templates and Rules (DTR): Payers define structured questionnaires and templates via DTR. These templates capture the necessary clinical documentation for authorization requests, helping providers submit complete and compliant requests. Providers can retrieve these templates using the $questionnaire-package operation.
• Prior Authorization Support (PAS): Payers use PAS to receive and process prior authorization requests from in-network providers.
  • Providers can submit new requests and check their status using the following APIs:
    • Prior Authorization Submission (Claim/$submit) – Submit new prior authorization requests.
    • Status Inquiry (Claim/$inquire) – Query the status of submitted requests.
  • Payers can also leverage Smile's custom operation to update authorization outcomes:
    • Payer Adjudication Update (ClaimResponse/$sdh.pa.submit) – Submit authorization outcomes; providers receive updates via subscriptions or Claim/$inquire.

Setting up the Prior Authorization Solution involves configuring the required pre-seeding files and FHIR resources, setting up the Smile HDP modules, defining FHIR endpoints, and enabling permissions for authorized users.

65.2.2Pre-Seed Required Files

Before module configuration, it is necessary to add and configure the following resource files:

Note: The Smile Support Team or Technical Account Manager should be contacted to obtain the reference files listed below.

1. Add the following files inside the config_seeding folder within the Smile classes folder:
   • search-parameters.json
   • com.search.parameters.tgz
2. Add routes.yaml directly in the Smile classes folder:
   • Open the file in a text editor and update the fields according to the specific configuration requirements.
3. Add the following JAR file(s) into the customerlib folder:
   • priorauth-pas-adjudication-2024.08.PRE2-20240716.180300-22.jar

65.2.3Start Smile

Once all required files have been added, start the Smile application. (See Quick Start Guide for reference.)

65.2.4Configure Required Modules

With Smile started and pre-seeding completed, the following modules need to be configured in order to enable Prior Authorization functionality. Each module has specific dependencies and settings, so follow the steps carefully to ensure proper setup.

65.2.4.1Configure FHIR Storage Module

On the FHIR Storage (R4 RDBMS) module (add it if it does not already exist, or update the existing module), configure the following properties:

1. Under FHIR Storage Package Registry, add the classpath for the pre-seed installation file (classpath:/config_seeding/search-parameters.json).
2. Confirm Database Settings:
   • Connection URL (default: H2_EMBEDDED)
   • Database Username and Password 3. Under FHIR Subscription Persistence, enable REST Hook Subscription.
3. Leave everything else as default values.
4. Save and start (or restart) the module as needed.

65.2.4.2Configure the Subscription Matcher Module

On the Subscription Matcher module (add it if it does not already exist), configure the following properties:

1. Under Dependencies:
   • FHIR Storage Module: set to the previously configured FHIR Storage module.
2. Save and start the module.

65.2.4.3Configure the FHIR REST Endpoint Module

On the FHIR REST Endpoint module (add it if it does not already exist), configure the following properties:

1. Add a Listener Port: (e.g., 8000).
2. Add Context Path: (e.g.,/payer-fhir)
3. Under the FHIR REST Endpoint section, set the Fixed Value for the Endpoint Base URL. (e.g., https://<host>/payer-fhir)
4. Add Dependencies:
   • Username/Password Authentication: local_security (Local Inbound Security)
   • FHIR R4 Storage: Set to the previously created FHIR Storage module.
5. Save and start the module.

65.2.4.4Configure the CQL Module

On the CQL module (add it if it does not already exist), configure the following properties:

1. Leave all configurations as default.
2. Add Dependencies:
   • FHIR Endpoint: set to the previously configured FHIR REST Endpoint module.
3. Save and start the module.

65.2.4.5Configure the CDS Hooks REST Endpoint Module

On the CDS Hooks REST Endpoint module (add it if it does not already exist), configure the following properties:

1. Under CDS Hooks Definitions:
   • FHIR Version: Set to R4
2. Under CDS Hooks On FHIR:
   • Enable CDS on FHIR: Toggle to Yes 3. Under HTTP Listener:
   • Listener Port: Set the TCP Port which this module listens to (e.g., 8003)
   • Context Path: Set to /crd.
3. Add Dependencies:
   • FHIR Endpoint: set to the previously configured FHIR REST Endpoint module
   • CQL: Select the previously created CQL module used for evaluating CQL Libraries.
4. Save and start the module.

65.2.4.6Configure the Prior Auth CRD Module

Add the Prior Auth CRD module and configure the following properties:

1. Under Prior Authorization Coverage Requirement Discovery, fill in the properties according to the organization’s configuration.
   • CDS Hook: Add the CDS Service JSON (including prefetch keys). Example:

   {
       "hook": "order-sign",
       "title": "Order sign request",
       "description": "A CDS Hook for order sign requests",
       "prefetch": {
           "serviceRequestBundle": "ServiceRequest?_id={{context.draftOrders.ServiceRequest.id}}&_include=ServiceRequest:performer&_include=ServiceRequest:requester&_include:iterate=PractitionerRole:practitioner&_include:iterate=PractitionerRole:organization&_include:iterate=PractitionerRole:location",
           "deviceRequestBundle": "DeviceRequest?_id={{context.draftOrders.DeviceRequest.id}}&_include=DeviceRequest:performer&_include=DeviceRequest:requester&_include:iterate=PractitionerRole:practitioner&_include:iterate=PractitionerRole:organization&_include:iterate=PractitionerRole:location",
           "nutritionOrderBundle": "NutritionOrder?_id={{context.draftOrders.NutritionOrder.id}}&_include=NutritionOrder:provider&_include:iterate=PractitionerRole:practitioner&_include:iterate=PractitionerRole:organization",
           "patient": "Patient/{{context.patientId}}",
           "coverageBundle": "Coverage?patient={{context.patientId}}&status=active&_include=Coverage:payor"
       }
   }
   

   • Alternatively, configure the CDS Hook prefetch to handle an unlimited number of queries. Example:

     {
         "hook": "order-sign",
         "title": "Order sign request",
         "description": "A CDS Hook for order sign requests",
         "prefetch": {
             "serviceRequestBundle": "ServiceRequest?_id={{context.draftOrders.ServiceRequest.id}}&_include=ServiceRequest:performer&_include=ServiceRequest:requester",
             "serviceRequestBundle2": "PractitionerRole?_has:ServiceRequest:performer:_id={{context.draftOrders.ServiceRequest.id}}&_include=PractitionerRole:practitioner",
             "deviceRequestBundle": "DeviceRequest?_id={{context.draftOrders.DeviceRequest.id}}&_include=DeviceRequest:performer&_include=DeviceRequest:requester",
             "nutritionOrderBundle": "NutritionOrder?_id={{context.draftOrders.NutritionOrder.id}}&_include=NutritionOrder:provider",
             "patient": "Patient/{{context.patientId}}",
             "coverageBundle": "Coverage?patient={{context.patientId}}&status=active&_include=Coverage:payor"
         }
     }
     

2. Under Camel:
   • Camel Routes (File): set to the CRD Routes file (e.g., classpath:/config_seeding/crd-routes.xml) or to the organization’s custom routes file..
   • Camel Functions ( File): set to the CRD Camel Functions file (e.g., classpath:/config_seeding/crd-functions.js) or to the organization’s custom functions file.
3. Add Dependencies:
   • Endpoint CDS Hooks: Select the previously created CDS Hooks REST Endpoint module.
4. Save and start the module.

65.2.4.7Configure the Prior Auth DTR Module

Add the Prior Auth DTR module and configure the following properties:

1. Under Prior Authorization Documentation Templates and Requirements, confirm that Enable $questionnaire-package is set to Yes.
2. Add Dependencies:
   • CQL: select the previously configured CQL module.
   • FHIR Endpoint: select the previously configured FHIR REST Endpoint module.
3. Save and start the module.

65.2.4.8Configure the Prior Auth PAS Module

Add the Prior Auth PAS module and configure the following properties:

1. Under Prior Authorization Support Settings:
   • Intermediary System Organization Reference – Set to Organization/SmileDigitalHealth
   • Payer System Item TRN (payer_system_item_trn) – Set to the identifier system that the payer uses for tracking item-level transactions (TRNs) in prior authorizations (e.g., http://sdh-mockpayer.org/ITEM_TRACE_NUMBER).
   • Organization Identifier Code System NPI (organization_npi_identifier_code_systems) – Set to the identifier system (e.g. http://hl7.org/fhir/sid/us-npi).
   • Practitioner Identifier Code System NPI (practitioner_npi_identifier_code_systems) – Set to the practitioner identifier system (e.g., http://hl7.org/fhir/sid/us-npi) .
2. Add Dependencies:
   • FHIR Endpoint: select the previously configured FHIR REST Endpoint module.
3. Save and start the module.

65.2.5Procedure and Prior Authorization Codes

For the CDS Hook to function correctly, the payer FHIR repository must include the following ValueSets:

• Procedure Codes: A ValueSet of procedure codes that are accepted and do not require prior authorization. This allows providers to quickly identify which procedures can be performed without additional approvals.
• Prior Authorization Codes: A ValueSet of codes that do require prior authorization. This ensures that the CDS Hook can prompt providers to submit the necessary documentation for review before proceeding.

65.2.6Validate CDS Hook Services

After configuring all modules, validate the CDS Hook services using Postman or Insomnia:

1. Perform a GET request to: {{base_url}}/{{cds_hooks_rest_endpoint_module_context_path}}/cds-services
2. Confirm that the expected list of services is returned.
3. Submit a Prior Auth request to the service: {{base_url}}/{{cds_hooks_rest_endpoint_module_context_path}}/cds-services/{{prior_auth_module_id}}
   • Example: http://localhost:8007/crd/cds-services/prior_auth_crd

This ensures that the modules, routes, and dependencies are correctly wired.

65.2.7Ingest FHIR Reference Data

To support testing and proper operation of the Prior Authorization Solution, certain reference FHIR resources are required.

Note: These reference files can be obtained from Smile Support or your Technical Account Manager.

1. Upload the provided FHIR resources to the FHIR repository.
   • Use a POST request to send each resource to the Payer Endpoint (https://<host>/<fhir-payer>)
2. Reference resources typically include
   • SearchParameter definitions
   • Patient records
   • Practitioner records
   • Organization records
   • Location records
   • PractitionerRole records
   • Coverage records
   • Subscription bundles for PAS requests
   • CQL library resources 3. Launch a tool such as Postman or Insomnia.
3. After ingesting all resources, restart the CQL Module to ensure the changes are applied.