Claim Queue

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 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.

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.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.

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.

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.

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

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;

Electronically confirmed submissions by biller

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;

Stranded claims from an unfinished submission run

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;

Oldest claims still waiting in the queue

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;

If you have any questions about this topic please reach out to Elation Support Portal with the subject line HDB - <your_question>

Hosted Database

Overview

How Tos

Common Queries

Elation Billing

Frequently Asked Questions

Early Release

Changelog

Claims currently waiting to be submitted

Electronically confirmed submissions by biller

Stranded claims from an unfinished submission run

Oldest claims still waiting in the queue

​Claims currently waiting to be submitted

​Electronically confirmed submissions by biller

​Stranded claims from an unfinished submission run

​Oldest claims still waiting in the queue

Claims currently waiting to be submitted

Electronically confirmed submissions by biller

Stranded claims from an unfinished submission run

Oldest claims still waiting in the queue