> ## Documentation Index
> Fetch the complete documentation index at: https://help.elationhealth.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Claim Queue

> See which claims were queued for submission to the clearinghouse, when, and by which biller.

One row per claim queued for submission to the clearinghouse.

This table is mostly history, not a live worklist. Elation Billing removes a claim from its queue once the claim leaves it, so well over 99% of rows are completed work rather than pending work. **Any question about what is waiting to be submitted must filter on `is_deleted = false`** - a plain row count over the whole table will overstate pending work by several orders of magnitude.

Those completed rows are kept because they are the only record in the Hosted Database of which biller pushed a claim out the door and when. [claim](/articles/hdb/claim) carries no user, and no other Elation Billing table attributes a claim submission to a person.

This table's columns and relationships are shown in the [Hosted Database schema](/articles/hdb/schema).

<Note>
  A row that has left the queue records neither why it left nor when. `created_timestamp` is the only timestamp on this table, so the time a claim spent in the queue can be measured only for claims still in it. For when a claim was actually submitted, use [clearinghouse\_transaction](/articles/hdb/clearinghouse-transaction).

  `is_submitted` identifies the rows Elation Billing confirmed it submitted electronically. Paper submissions are deliberately not counted - they leave the queue without the batch label `is_submitted` depends on, and cannot be told apart from a biller pulling the claim back - so `is_submitted = false` means not electronically confirmed, not necessarily unsubmitted. For the billing outcome itself use `clearinghouse_transaction` and `claim.is_billed`.
</Note>

<Note>
  `status` has two values Elation Billing defines: `pending`, meaning queued and awaiting a biller marking it ready, and `ready`, meaning cleared for the next submission run. A third form, `batch-` followed by a timestamp, is an internal label applied while a group of claims is being submitted.

  The same value means different things depending on `is_deleted`. On a row that has left the queue, `pending` means the claim was paper billed or pulled back by a biller, and a `batch-` label is the audit trail of the run that submitted it. On a row still in the queue, a `batch-` label should exist only momentarily, so a surviving one means that submission run did not finish and the claim is stranded.
</Note>

<Note>
  `patient_insurance_id` is the insurance the claim was queued to be billed to, which is not necessarily the one it was last billed to. It is only meaningful on rows still in the queue.
</Note>

**For reporting on but not limited to:**

* Which claims are waiting to be submitted right now
* Which biller queued a claim, and when
* How long the claims currently queued have been waiting
* Electronically confirmed submissions over time, by biller or practice
* Stranded claims left behind by an unfinished submission run

## Claims currently waiting to be submitted

<CodeGroup>
  ```sql sql theme={null}
  select
      cq.created_timestamp
    , pt.full_name
    , cq.claim_id
    , cq.status
    , concat_ws(' ', u.first_name, u.last_name) as queued_by
    , pi.carrier as insurance_to_bill
  from claim_queue cq
    left join claim c on c.id = cq.claim_id
    left join patient pt on pt.id = c.patient_id
    left join elation_billing_user u on u.id = cq.elation_billing_user_id
    left join patient_insurance pi on pi.id = cq.patient_insurance_id
  where not cq.is_deleted
  order by cq.created_timestamp;
  ```
</CodeGroup>

## Electronically confirmed submissions by biller

<CodeGroup>
  ```sql sql theme={null}
  select
      concat_ws(' ', u.first_name, u.last_name) as biller
    , u.email
    , count(*) as claims_submitted
    , min(cq.created_timestamp) as first_queued
    , max(cq.created_timestamp) as last_queued
  from claim_queue cq
    left join elation_billing_user u on u.id = cq.elation_billing_user_id
  where cq.is_submitted
  group by u.first_name, u.last_name, u.email
  order by claims_submitted desc;
  ```
</CodeGroup>

## Stranded claims from an unfinished submission run

<CodeGroup>
  ```sql sql theme={null}
  select
      cq.created_timestamp
    , p.name as practice_name
    , pt.full_name
    , cq.claim_id
    , cq.status
  from claim_queue cq
    left join claim c on c.id = cq.claim_id
    left join patient pt on pt.id = c.patient_id
    left join practice p on p.id = cq.practice_id
  where not cq.is_deleted
    and cq.status ilike 'batch-%'
  order by cq.created_timestamp;
  ```
</CodeGroup>

## Oldest claims still waiting in the queue

<CodeGroup>
  ```sql sql theme={null}
  select
      p.name as practice_name
    , pt.full_name
    , cq.claim_id
    , cq.status
    , cq.created_timestamp
    , datediff(day, cq.created_timestamp, current_date) as days_waiting
  from claim_queue cq
    left join claim c on c.id = cq.claim_id
    left join patient pt on pt.id = c.patient_id
    left join practice p on p.id = cq.practice_id
  where not cq.is_deleted
  order by cq.created_timestamp;
  ```
</CodeGroup>

*If you have any questions about this topic please reach out to [Elation Support Portal](/articles/support-portal-introduction) with the subject line HDB - \<your\_question>*