2.11 End-to-end test (golden path)

Outcome

A real (or test-mode) claim flows from member intake → eligibility check → service encounter → claim build → submission → ack → ERA → payment posting, in the customer's configured tenant.

Prerequisites

• 2.10 Users and RBAC complete.
• A test member, test payer (sandbox endpoint), and a test billing entity in place.

Golden-path workflow

Steps

1. Add a test member

   Sign in as a MEMBER_SERVICES user. Members → Add member. Use a synthetic SSN/MRN to avoid PHI confusion.

2. Add insurance coverage to the member, pointing at a test payer plan with a test member ID known to the payer's test endpoint.

3. Run an eligibility check (270)

   Eligibility → New eligibility check → Real-time. The platform sends 270, waits ~3s for 271, parses, and shows coverage status, copay, and benefit details.

   If the payer is batch-only, the request queues and the 271 returns at the next batch window.

4. Optionally request authorization (278)

   If the program config requires it: Authorizations → New 278 request. The platform posts the 278 and tracks the response (approved / pended / denied).

5. Create a service encounter

   Sign in as a BILLER (or have the customer's billing test user do this).

   Encounters → New encounter:

   • Member: from step 1
   • DOS: today
   • Service: 90837 (psychotherapy)
   • Modifiers: HO (master's-level)
   • Rendering provider: a test clinician
   • Place of service: 11 (office)
   • Site: from 2.5

6. Build and scrub the claim

   Claims → New from encounter → review scrub results.

   The scrub panel shows:

   • Modifier injection (e.g. + U7 from a tenant rule).
   • Filing-window check.
   • NPI checks.
   • CCI/MUE conflicts.
   • Auth presence (if required).

   Resolve any errors; warnings can pass through.

7. Submit the claim

   Claims → <claim> → Submit. The platform builds the 837P, routes via the configured trading partner (2.9), and queues for transmission.

8. Verify the 277CA acknowledgment

   Within 24 hours, the partner returns 277CA. Confirm:

   • Claims → <claim> status moves to Acknowledged.
   • EDI → Acknowledgments → 277CA shows the parsed STC reason codes.

9. Verify the 835 (ERA)

   When the payer adjudicates and remits payment, the 835 lands in Receivables → Inbox. Confirm:

   • The platform auto-matches the 835 line to the original claim.
   • Receivables → Auto-matched shows the line; clicking opens the matched-claim trace.
   • Posting the ERA writes ledger entries (paid amount, PR adjustment, CO adjustment).

Validation

Check	Expected
member row	1 for the test member
eligibility.eligibility_response row	1 with status active
claim.claim row	1, status progresses DRAFT → SUBMITTED → ACKNOWLEDGED → PAID
edi.outbound_batch row	1 with the 837 file content
edi.inbound_batch rows	1 each for 277CA + 835
billing.ledger_entry rows	1 per posted line
identity.tenant_audit	claim-lifecycle events present

Troubleshooting

Symptom	Likely cause	Fix
270 returns immediately with error	Payer endpoint mismatch in trading partner config	Verify Connection config in the partner row.
Scrubber blocks claim with MODIFIER_REQUIRED	Tenant rule expects a modifier the encounter didn't capture	Either fix the encounter, or update the rule scope.
277CA never arrives	Test partner not yet certified	Complete the test cycle from 2.9 step 6.
835 doesn't auto-match	Claim's payer_claim_control_number mismatch	Inspect Receivables → Unmatched and use Manual match.

Next

2.12 — Go-live