Revenue Cycle Management (RCM)

Trust tier roll-up

RBAC matrix (IC 0–100 scale)

Claim submission hard rule: Only users with level ≥ 70 (billing manager) can submit a claim to the clearinghouse. Coders (level 50) can edit and scrub, but submission requires manager approval. Clinicians (level 60) sign off on charge capture at encounter close but do not submit claims directly.

FK Relationship Diagram

erDiagram
    Patient ||--o{ Claim : "has"
    Encounter ||--o{ Claim : "generates"
    Provider ||--o{ Claim : "renders"
    Claim ||--o{ ClaimLine : "contains"
    Claim ||--o{ Payment : "receives"
    Claim ||--o{ Denial : "may have"
    Patient ||--o{ PatientStatement : "owes"
    

Claim State Machine

stateDiagram-v2
    [*] --> Draft
    Draft --> Scrubbed : Auto-scrub rules pass
    Scrubbed --> Submitted : Send to clearinghouse
    Submitted --> Accepted : Payer accepts
    Submitted --> Denied : Payer denies
    Accepted --> Paid : Full payment received
    Accepted --> PartiallyPaid : Partial payment received
    Accepted --> Denied : Post-acceptance denial
    PartiallyPaid --> Paid : Remaining balance paid
    PartiallyPaid --> WrittenOff : Balance written off
    Denied --> Submitted : Appeal resubmission
    Denied --> WrittenOff : Write off denied balance
    Draft --> Voided : Cancel before submission
    Scrubbed --> Voided : Cancel before submission
    Paid --> [*]
    WrittenOff --> [*]
    Voided --> [*]
    

Functional Requirements

1. P0 The system SHALL create claims from encounter data with CPT, ICD-10, and modifier codes on claim lines.
2. P0 The system SHALL auto-scrub claims against payer-specific rules before submission and flag errors for correction.
3. P0 The system SHALL submit claims electronically via clearinghouse (ANSI X12 837P/837I) and track clearinghouse acknowledgments.
4. P0 The system SHALL process ERA (835) remittance files and auto-post payments to corresponding claims.
5. P0 The system SHALL track claim status through the full lifecycle (Draft through Paid/WrittenOff/Voided) with immutable audit.
6. P1 The system SHALL capture denial codes (CARC/RARC), categorize denials, and track appeal deadlines.
7. P1 The system SHALL generate patient statements consolidating patient responsibility across claims.
8. P1 The system SHALL support payment plans with scheduled installment tracking on PatientStatement.
9. P1 The system SHALL provide denial root-cause analytics (MissingAuth, CodingError, TimelyFiling) for process improvement.
10. P1 The system SHALL allow billing managers to submit appeals with supporting documentation before appeal deadlines.
11. P1 The system SHALL support secondary and tertiary claim submission when primary payer adjudication is complete.
12. P2 The system SHALL provide aging reports (30/60/90/120+ days) for accounts receivable management.
13. P2 The system SHALL support batch claim submission and batch ERA posting for high-volume practices.
14. P2 The system SHALL allow clinicians to review and sign off on coding before claim submission.
15. P2 The system SHALL display patient statements in the patient portal with online payment capability.
16. P2 The system SHALL support write-off workflows with configurable approval thresholds by dollar amount.

Non-Functional Requirements

• Latency: Claim scrubbing completes within 3 seconds per claim (99th percentile).
• Throughput: Support batch submission of 10,000 claims per hour per organization.
• Availability: Claim submission service 99.95% uptime; queued retry for clearinghouse failures.
• Audit: Every claim status transition logged with actor, timestamp, before/after values; immutable; retained 10 years.
• Encryption: All financial data encrypted at rest (AES-256); TLS 1.2+ in transit to clearinghouse.
• Compliance: HIPAA transaction standards (ANSI X12 837/835); timely filing tracked per payer contract.
• Reconciliation: ERA auto-posting accuracy 99.5%+ with exception queue for manual review.
• Scalability: Support organizations with 50,000+ active claims without query degradation (< 500ms for list views).

icApplication Overrides

How the five RCM AMI schemas turn into a live application: module-specific stack additions, override component bindings, the clearinghouse integration pipeline, the denial triage & appeal pipeline, a versioning worked example, environment cascade, and RBAC enforcement.

Technology stack P0

The shared platform stack (Cosmos DB, Redis, IC-generated API, Angular 21, SQS+SNS, OpenTelemetry, etc.) is documented in the IC Reference. Module-specific additions:

RCM-specific override bindings P0

These overrides are declared in rules/*.rules.json and replace the default for the matching field name pattern.

Clearinghouse integration pipeline P0

Claim submission and remittance ingestion flow through two clearinghouse connectors. Waystar is primary; Availity is used for direct-connect payers that require it (some BCBS plans). Both are BUY integrations per the Integration Ecosystem decision.

flowchart LR
  CLAIM[Claim ready
Status = Scrubbed]
  WAYSTAR[Waystar
primary]
  AVAILITY[Availity
secondary]
  PAYER[Payer
adjudication]
  ERA[ERA/835
remittance]
  CLAIM --> WAYSTAR
  CLAIM --> AVAILITY
  WAYSTAR --> PAYER
  AVAILITY --> PAYER
  PAYER --> ERA
  ERA --> POSTING[Auto-posting
+ Denial routing]
    

The waystar-clearinghouse.ts adapter handles 837P serialization, 276/277 polling, and ERA/835 deserialization. The availity-clearinghouse.ts adapter handles direct-connect payer routing. Payer routing rules are maintained in rules/claim.rules.json and specify which PayerIDString50 values route through Availity vs. Waystar.

Denial triage & appeal pipeline P0

Denied claims are processed through an AI-powered triage pipeline that categorizes, routes, and enables appeal generation:

flowchart TD
  DENIAL[Denial received
from ERA/835]
  TRIAGE[AI Triage Engine
BERT classifier]
  CAT{Category?}
  QUEUE[Work Queue
assignment]
  APPEAL[Appeal Letter
Generator]
  SUBMIT[Appeal Submitted
to payer]
  TRACK[SLA Tracking
+ Escalation]
  DENIAL --> TRIAGE
  TRIAGE --> CAT
  CAT -- Eligibility --> QUEUE
  CAT -- Authorization --> QUEUE
  CAT -- Coding --> QUEUE
  CAT -- TimelyFiling --> QUEUE
  CAT -- COB --> QUEUE
  CAT -- MedicalNecessity --> QUEUE
  QUEUE --> APPEAL
  APPEAL --> SUBMIT
  SUBMIT --> TRACK
    

The denial-triage-worker.ts job consumes denials from the ERA ingestion queue, runs them through the BERT-based classifier, populates Denial.DenialCategoryString50 and Denial.RootCauseString50, and routes to the appropriate work queue. The appeal-letter-generator.ts adapter generates appeal letters with regulatory citations when the billing manager initiates an appeal. The appeal-deadline-monitor.ts job tracks SLA deadlines and escalates via Task Management.

Versioning — worked example P0

All RCM artifacts are versioned break.feature.bug.buildtimestamp per IC hard rule #9. The example below traces a feature bump on Claim.

Claim 1.0.0.20260401T120000Z — Initial schema. 14 business fields plus four org-scoped audit columns. Component ic-ng21-rcm-1-charge-capture and ic-ng21-rcm-1-claim-submit bind to claim@1.0.0.* via the DI manifest.

Claim 1.1.0.20260715T093000Z — feature bump — Adds a single optional field, SecondaryPayerIDString, to support explicit secondary payer tracking on the claim header (previously derived from Eligibility COB data at runtime). Per the IC change matrix:

Because the change is backward-compatible, the component tag stays ic-ng21-rcm-1-charge-capture. Existing UI consumers continue to bind claim@1.x.* and ignore the new field. New UI surfaces that need explicit secondary payer display bind claim@^1.1.0. No new database is required (IC rule #13 only applies to break bumps).

Claim 2.0.0.20280101T120000Z — break bump (illustrative) — An illustrative future break bump: StatusString50 is replaced with a StatusInt enum-backed integer for faster index scans and type safety. Per the IC change matrix this is change field type — break bump, EditAMI (90) approval, and per IC rule #13 a new database is provisioned with ETL from the old one. The component tag becomes ic-ng21-rcm-2-charge-capture; consumers must re-bind. The old database stays live for the configured grace period (default 90 days) for rollback.

RCM environment details

RCM RBAC notes

• Claim submission gate. Claim submission is gated at level ≥ 70 (billing manager). Appeal submission is gated at level ≥ 70. Write-off approval requires level ≥ 80 (practice admin).
• Clearinghouse submission gate. The claim-submit component enforces that only claims with StatusString50 = "Scrubbed" can be submitted, and only by users with level ≥ 70. The API layer re-validates both conditions server-side.

Cross-Module Dependencies

• Clinical Documentation — charge capture reads encounter procedures, immunizations, and POC lab results from the global clinical record at encounter close. The encounter is the source entity for Claim.EncounterID.
• Coding / CDS — AI coding suggestions and the scrubbing rules library (NCCI, MUE, LCD/NCD) are authored and versioned in Coding/CDS. RCM invokes them in the claim pipeline via CDS Hooks and the rules API.
• Eligibility — eligibility verification at charge capture confirms active coverage before the claim is submitted. Coordination of benefits data from Eligibility feeds the secondary/tertiary auto-claim logic.
• Patient Portal — patients view statements, pay bills, enroll in payment plans, and dispute charges through the portal’s billing surface. Payment events from the portal flow back into the Payment entity.
• Task Management — denial work queues, appeal deadlines, scrubbing warnings, and escalation alerts surface as tasks in the billing team’s inbasket.
• Data Model — all five RCM noun-apps (Claim, ClaimLine, Payment, Denial, PatientStatement) are org-scoped with standard three audit fields plus OrganizationID, following the operational-is-org-scoped pattern. Patient, Encounter, and Provider are global entities referenced via FKs that cross the org boundary.

Cross-Module Links

• Patient Portal — patient statements and online payments
• Task Management — denial follow-up and appeal tasks
• Payer Optimization — coding suggestions and scrub rules
• eRx & EPCS — prior-auth decisions feed claim adjudication
• Referrals — referral auth status impacts claim submission