New Tables
Release Highlights
elation_billing_user One row per Elation Billing user, per warehouse. elation_billing_user is the first table to name the people behind Elation Billing activity, and it is what makes the user references onclaim_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 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.
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, 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 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 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 and claim.is_billed.
charge_dx
One row per diagnosis code per charge line, ordered by sequence_number. 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 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 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 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.
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.