> ## 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.
# 2026-08-31
This release adds six Elation Billing tables: the people who work claims, the queue they submit them from, the diagnosis codes on each charge line, the payer addresses paper claims are mailed to, and the notes billers leave on claims and on payments.
## New Tables
| Table | Description |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| elation\_billing\_user | The billers, administrators, and practice staff who work claims in Elation Billing, with their role, contact details, and last login. |
| claim\_queue | Claims queued for submission to the clearinghouse, recording which biller sent each claim out and when. |
| charge\_dx | The diagnosis codes attached to each Elation Billing charge line, in the order they appear on the claim. |
| payer\_address | The mailing addresses a practice holds for each payer, used for paper claim runs. |
| claim\_note | Notes billers leave on an Elation Billing claim - the note text, the user who wrote it, and when. Every note is attributed to a user. |
| payment\_note | Notes recorded against an Elation Billing payment - the note text, who wrote it, and when. Notes come either from a billing user or from the EHR patient-payment integration. |
***
## Release Highlights
**elation\_billing\_user**
One row per Elation Billing user, per warehouse. [elation\_billing\_user](/articles/hdb/elation-billing-user) is the first table to name the people behind Elation Billing activity, and it is what makes the user references on `claim_queue`, `claim_note`, and `payment_note` resolve to a named person.
Elation Billing accounts are separate from the Elation EHR users in `user`; join through [elation\_sso\_user](/articles/hdb/elation-sso-user) to connect the two. There is no `practice_id` on this table, because one user can work across several practices - the practices they work in are in [user\_practice](/articles/hdb/user-practice).
`is_active` and `is_deleted` mean different things. `is_active = false` is a user whose access was withdrawn but whose record remains; `is_deleted = true` is a record removed in Elation Billing. Filter on both when you want only current, usable accounts. `role_id` points at [user\_role](/articles/hdb/user-role), but a small number of users carry a role that no longer exists there, so use a left join if you need every user in the result.
**claim\_queue**
One row per claim queued for submission to the clearinghouse. [claim\_queue](/articles/hdb/claim-queue) is mostly history rather than a live worklist: Elation Billing removes a claim from the queue once the claim leaves it, so well over 99% of rows are completed 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 sent a claim out and when. [claim](/articles/hdb/claim) carries no user, and no other Elation Billing table attributes a claim submission to a person.
`status` changes meaning with `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. `is_submitted` covers electronically confirmed submissions only; for the billing outcome itself use [clearinghouse\_transaction](/articles/hdb/clearinghouse-transaction) and `claim.is_billed`.
**charge\_dx**
One row per diagnosis code per charge line, ordered by `sequence_number`. [charge\_dx](/articles/hdb/charge-dx) is the Elation Billing counterpart to `bill_item_dx` on the Elation EHR side.
There is no `id` column. Elation Billing holds no single key for these rows, so a row is identified by its charge, diagnosis code, and sequence together - all three parts are needed, because neither charge and sequence nor charge and code is unique on its own.
`dx` holds the ICD-10 code with the decimal point removed: `I10`, `E785` for E78.5, `Z0000` for Z00.00. This matches the format used by `bill_item_dx.dx`, so it does not join directly to `icd10.code` without reinstating the decimal point.
**payer\_address**
One row per saved payer mailing address. A practice can hold more than one address for the same payer.
[payer\_address](/articles/hdb/payer-address) is an address book kept against the Claim.MD payer directory rather than against the practice's own saved payer list, so `payer_id` resolves on roughly two thirds of rows. The rest are directory payers the practice holds a mailing address for but has never saved as a payer of its own. `claimmd_payer_id` is populated on every row, so use it rather than `payer_id` when you need payer identity across the whole table.
`claimmd_payer_id` is held as text, and not every value is numeric - `PAPER`, `EAP20`, and `00060` are all valid codes - so leading zeros are significant and it should not be cast to a number. `zip` formatting is inconsistent in the source, in both five-digit and nine-digit forms with and without a hyphen, so normalize it before matching on it.
**claim\_note**
One row per note per claim. Until now the Hosted Database had no way to answer who worked a claim and what they said about it: `claim.narrative` and `charge.line_note` hold only the current text with no author and no history, and `worklist_reason` records when a claim was worklisted but not by whom. [claim\_note](/articles/hdb/claim-note) is the full trail, oldest note to newest, with an author on every row.
Join on `claim_id` to reach the claim, and on `elation_billing_user_id` to reach the author's name and login. Attribution is complete: every note carries a user.
`is_statement_note` marks notes flagged with the star toggle in the claim notes panel, which are the notes counted toward the patient's statement. Filter on `is_deleted = false` for the notes still visible in Elation Billing.
**payment\_note**
One row per note per payment. Notes reach [payment\_note](/articles/hdb/payment-note) by two paths, and the difference matters when you report on them.
A billing user working the payment in Elation Billing produces a note with `elation_billing_user_id` set, which joins to `elation_billing_user` for the author's name. The EHR patient-payment integration, which posts payments taken in the EHR, produces notes with no `elation_billing_user_id` and text prefixed `INTERNAL MEMO - `. These are the majority of notes today, so a null user id means system-created rather than unknown, and an inner join to `elation_billing_user` will drop them.
`author_login` is a snapshot of the author's login taken when the note was written. A user who was later deactivated keeps their old login on historical notes, so it will not always match the current `elation_billing_user.email`. Treat it as display text, not a key.
Every column on all six tables is described in the [Hosted Database schema](/articles/hdb/schema).
The tables in this release are present only for practices on the Elation Billing product. If your practice is not on Elation Billing, they are not created in your Hosted Database.
*If you have any questions about this topic please reach out to [Elation Support Portal](/articles/support-portal-introduction) with the subject line HDB - \*