Charges worklist

Outcome

You can navigate the Charges page, find the charges ready to bill, group them sensibly, and act on them in batches without breaking the "one-claim, one-payer, one-filing-type" rule.

Prerequisites

Scope	What it lets you do
billing.charge.read	View the worklist
billing.charge.write	Edit a charge inline (rare — see 2.6)
billing.claim.write	Build a claim from selected charges

The page

/charges opens with three primary regions:

Region	Purpose
Filter rail	Status, facility, payer, program, date-of-service, member, source-feed.
List	One row per charge; columns are tunable.
Inline drawer	Opens on row-click; edit + source-record + history.

Defaults narrow to VALIDATED charges with active coverage on the date of service. If a row is missing it's probably in NEEDS_FIX; switch that filter on.

Group-by modes

The toolbar's Group by chip changes the row shape, not the filter:

Group by	What you see
None (default)	One row per charge.
Member	Member rows expand to their charges. The default sort is by date-of-service ascending.
Facility	Site rows; useful for multi-site clerks.
Program	Program rows; useful when programs have different filing types.
Source feed	Feed rows; useful when chasing an ingestion problem.

Selection rules (the hard floors)

The platform enforces these the moment you start selecting:

Rule	Why
One member per claim	A claim is per-member by definition.
One primary payer per claim	The payer responsibility column lives at the claim header.
One filing type per claim (P vs I)	Professional and institutional submit on different forms (837P vs 837I).
Same facility (configurable)	Some payers reject mixed-facility claims; default is enforced.

Selecting a mix greys out Build claim with a tooltip explaining the conflict. Don't disable the check — split the selection.

Common selection patterns

Goal	How
One claim per member-day	Group by member, expand, select all charges in a date.
One claim per encounter	Group by member, select rows tagged with the same encounter_id.
Bulk all of today's outpatient	Group by program, select all Outpatient program rows; build one claim per member automatically.
Bulk a per-diem stay	Group by member, select all DOS rows in the stay; the platform builds a 837I (see 3.7).

Build a claim

1. Pick your selection under the rules above.

2. Click Build claim. The platform creates a CREATED-status claim per (member, payer, filing-type) tuple — usually one. The scrubber runs immediately. See 3.1 — Build & submit.

3. Land on the new claim's detail page. The Validation tab tells you whether the scrubber raised anything.

Bulk actions on charges (without building a claim)

Sometimes you want to act on charges without immediately billing:

Action	What it does
Re-validate	Re-runs the validator (after an upstream fix or rule edit).
Tag for review	Adds a tenant-defined tag to surface for triage.
Hold	Marks the charge ON_HOLD; excludes from default filters.
Release hold	Returns to normal.
Void	Cancels the charge; reversible only by re-ingest under a new natural key.

Tags are searchable in the filter rail. Holding is the right move when upstream is fixing a problem and you don't want the charge accidentally billed in the meantime.

Validation

Check	Expected
Build claim advances to CREATED	Yes.
Inline drawer's Source record opens	Yes.
Re-validate re-checks rules without changing fields	Yes.
Bulk hold updates each row's status	Yes; refresh the list to confirm.

Troubleshooting

Symptom	Cause	Fix
Rows missing	Filter rail too narrow	Reset filters; re-apply one at a time.
Build claim greyed	Selection breaks a hard rule	Hover the button; the tooltip names the rule.
Newly-validated charges still grey	List is stale	Click Refresh (or wait the 30-second auto-refresh).
Group-by shows zero rows	Group has no charges in current filter	Widen the filter (date range, status).

Where to next

• 2.3 — Fix validation issues for the NEEDS_FIX queue.
• 3.1 — Build & submit for the scrubber and submission flow.