Build & submit a claim

Outcome

Validated charges grouped onto a clean claim, the claim built into the right 837 (P or I), submitted to the right trading partner, and tracked through 999 / 277CA acknowledgment to ACCEPTED.

Prerequisites

Scope	What it lets you do
billing.charge.read	View the charges worklist
billing.claim.read	View list / detail
billing.claim.write	Build, submit, reverse

The charges you want to bill are already validated. Charges arrive in the platform from clinical encounters, group sessions, EVV visits, or bulk charge entry — see the Clinical category for those flows. A charge is billable when its status is VALIDATED.

The claim lifecycle (recap)

CREATED → BUILT → SUBMITTED → ACK_RECEIVED → ACCEPTED → PAID / DENIED. See Status reference for the full diagram.

Steps

1. Open Charges → Ready to bill at /charges?status=VALIDATED. The default filters narrow to charges on members with active coverage. You can group by member, by facility, or by program.

2. Pick the charges you want on a single claim. The platform refuses to mix:

   Boundary	Why
   Different members	One claim = one member.
   Different payers	One claim = one primary payer.
   Different filing types	Professional and institutional submit on different forms.

   If you select a mix, the Build claim button greys out with a tooltip explaining the conflict.

3. Click Build claim. The platform creates a CREATED-status claim, attaches the charges, and runs the pre-submit scrubber:

   • Modifier injection — auto-adds modifiers per 5.4 — Edit modifier rules.
   • Validation rules — pre-submit modifier_validation, auth_required, bundle_check, etc., per 5.3 — Edit rules engine YAML.
   • Bundling — per CCI/MUE rules.
   • Pricing — applies the contracted fee schedule.

   If validation fails, the claim stays at CREATED with issues attached; fix the underlying charges or auth and click Re-validate.

4. Review the claim at /claims/:id. Tabs:

   Tab	What you see
   Header	Member, payer, dates, totals.
   Charges	The lines on this claim with prices and modifiers.
   Validation	Any pre-submit issues (none on a clean claim).
   Submission	Submission history with EDI trace.
   Relationships	Parent / child claims (rebill, COB chain).

5. Click Submit. The platform:

   • Promotes the claim to BUILT and writes an edi_transaction row.
   • Routes to the correct trading partner per the routing rules (see 5.6 — Manage trading partner credentials).
   • Renders the 837 (P or I) and queues the file for transport.
   • Promotes to SUBMITTED once the transport confirms delivery.

6. Watch acknowledgments arrive. The Submission tab will populate:

   Document	When
   999	Functional ack — the file parsed cleanly.
   277CA	Claim-level ack — the payer accepted or rejected the claim.
   835	Eventual remittance — see 2.4 — Post an ERA.

   A clean run flips the claim to ACCEPTED once the 277CA arrives.

Institutional claims

For per-diem stay billing, the platform builds 837I instead of 837P based on the program's institutionalBillingPeriod setting. The Institutional context tab on the claim detail (see Per-diem & institutional billing in the Clinical section) carries DRG, length-of-stay, occurrence codes — fields that travel as HI*DR, OCC-74, VAL-80/81 segments in the 837I.

Validation

Check	Expected
Build claim produces a CREATED claim	Yes.
Validation passes (clean charges)	Yes; otherwise the issues panel lists what to fix.
Submit advances to SUBMITTED	Yes.
999 + 277CA arrive within the partner's SLA	Yes — usually minutes for clearinghouses, hours for direct payers.
Claim flips to ACCEPTED	Yes, on a clean 277CA.

Troubleshooting

Symptom	Cause	Fix
Build claim greyed out	Selection mixes members / payers / filing types	Narrow the selection.
Validation fails on auth_required	No active auth covers the service	Cancel the build; create or attach an auth (see Manage authorizations in Clinical), then re-build.
Submission stays in BUILT, never advances	Trading partner credentials expired or routing rule misconfigured	Test connection on the partner (5.6); use the Routing Precedence simulator to confirm the right rule fires.
277CA rejects with A7 (acknowledged but invalid)	Companion guide violation	Open the 277CA in the Submission tab; the STC element carries the specific reason; usually a missing field or a malformed loop.
Claim flips back from SUBMITTED to BUILT	TA1 envelope rejection (file-level)	Look at the edi_transaction row's error_details; common causes are wrong ISA08 or a malformed envelope; rotate the partner's credentials and resubmit.

Next

2.2 — Work the denials worklist