Prior Auth Support Module Overview

EAP

Introduction

Prior Authorization Support (PAS) is a Smile CDR module that enables the direct submission of prior authorization requests from EHR systems. It streamlines and automates the prior authorization process between healthcare providers and payers, ensuring efficient, interoperable, and secure management of authorization requests.

Built on Fast Healthcare Interoperability Resources (FHIR) standards and aligned with HL7 Da Vinci Prior Authorization Support (PAS) implementation guidelines (IG), the PAS module enhances the prior authorization workflow with several key features.

Operations

Smile CDR supports the PAS IG with the following operations:

• Claim/$submit is used to submit a prior authorization request for adjudication. It accepts a single Bundle resource as input, which includes the PAS Claim Request along with any referenced resources. The output is either a single Bundle resource containing the PAS Claim Response and any referenced resources or an OperationOutcome resource in case of errors.
• Request flow — at a high level, the module performs the following steps for every Claim/$submit call:
  1. Camel exchange — the request is dispatched through the configured Camel route as the exchange body.
     1. [Optional] Validate the request — a provided Camel Processor can optionally validate the request body.
     2. [Optional] Validate the response — a provided Camel processor can optionally validate the Bundle returned by the adjudication.
  2. Persist the request — the Bundle is saved to the repository.
  3. Process the response — the response is run through the same processing path used by ClaimResponse/$sdh.pa.submit, making the ClaimResponse available to the Provider via polling or subscription push.
  4. Return — the resulting Bundle is returned to the caller.
• Starting v2025.08, camel route will be used for evaluation of a prior auth request for adjudication.
• The camel context contains :
  • Request Body: The camel exchange body, which is the PAS Request Bundle.
  • PriorAuthPasContextJson: This contains additional context for the request. This object is passed as a camel exchange property with key priorAuthPasContextJson.
• At the end of the camel exchange, the module expects the camel exchange to return FHIR Bundle as a Java object or in a String or Stream format.
• If the optional request/response validation Camel Processors are used, the module will perform the following validations:
  • Bundle structure: The first entry of the Bundle must be the Claim resource.
  • Reference resolution: Every reference present on the Claim must resolve to an entry within the same Bundle.
  • Insurer: Claim.insurer must be present.
  • Duplicate detection: An internal search is performed against the repository to check for an existing Claim with the same identifier.
  • Profile: meta.profile must match the profile expected for the requested workflow.
  • Update scenario: When the request represents an update, references on Claim.related are validated against the Bundle.
• URL: [base-fhir-endpoint]/Claim/$submit

• Claim/$inquire is used to check the status of prior authorization requests. It accepts a single Bundle resource as input, which includes the PAS Claim Inquiry Request along with any referenced resources. The output is either a single Bundle resource containing the PAS Claim Inquiry Response and any referenced resources or an OperationOutcome resource in case of errors.
• Request flow — like Claim/$submit, the inquire operation sends the request through the module's Camel context, on the direct:start-pas-inquire route, so the inquiry can be forwarded to a payer or adjudication system. The shipped processors answer the inquiry from the local repository:
  1. Validate the request — pasInquiryRequestBundleValidator validates the incoming Bundle (see default validations below).
  2. Search the repository — createInquireResponseProcessor searches for the previously-stored PAS Response Bundle from a prior Claim/$submit, and reshapes it into the inquiry response. The search is:
     • _profile = http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-pas-response-bundle
     • claimresponse.identifier = <system>|<value> (taken from the inquiry request's first Claim.identifier)
     • Sorted by _lastUpdated descending — the most recent matching Response Bundle is selected.
     • If no Response Bundle matches, the operation fails with HTTP 422 Unprocessable Entity.
• The module performs the following default validations on every request:
  • Bundle structure: The first entry of the Bundle must be the Claim resource.
  • Identifier: Claim.identifier must be present.
• The repository search above depends on the custom claimresponse.identifier SearchParameter being installed on the PAS persistence — see the payer setup guide for the SearchParameter Bundle.
• The route must terminate with the inquiry response in the message body, as a Bundle, as a JSON String, or as a JSON stream. A route that fails produces HTTP 500 Internal Server Error unless the failure is itself a FHIR error response, which is returned to the caller unchanged.
• URL: [base-fhir-endpoint]/Claim/$inquire

PAS Request Routing

To route the PAS Requests from healthcare providers to the payer, the following components are used:

FHIR Subscription are used to track PAS Request Bundles from Claim/$submit as they are created and updated in the FHIR repository, then pushing them to the payer-preferred message broker (i.e., Kafka or ActiveMQ).

{
    "resourceType": "Subscription",
    "id": "profile-pas-request-bundle",
    "status": "active",
    "criteria": "Bundle?_profile=http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-pas-request-bundle",
    "channel": {
        "type": "message",
        "endpoint": "channel:<indicate channel name>",
        "payload": "application/json"
    }
}

The Message Broker is a messaging system used as the communication channel to transmit prior authorization requests and updates to the payer. PAS Request Bundles, including new requests and updates, are pushed to this broker and then consumed by the payer to initiate the adjudication process.