Infrastructure for Revenue Cycle Chatbot (Patient Billing Support)

The billing chatbot must give patients accurate, compliant explanations of charges, coverage adjustments, and payment plan options — not approximations. This requires explicit documentation of payment plan eligibility rules (e.g., balances over $500, income thresholds, maximum term lengths), approved scripts for explaining common EOB line items, and escalation criteria. When 'financial hardship discount' criteria exist only in a billing manager's head, the chatbot either over-promises or denies incorrectly, generating complaints and compliance exposure.

Patient billing chatbot interactions — questions asked, payments processed, payment plans enrolled, escalations triggered — are captured through the chat platform logs, but not through a systematic capture process with required metadata fields. The baseline hc-rv capture context shows patient interactions (financial counseling, payment plans) are 'poorly logged.' L2 is achievable: regular capture practices exist for charges and payments, but conversation-level context capture requires structured improvement. This constrains Accessibility to L2 per dependency rules.

Patient billing data presented by the chatbot must follow consistent schema: Claim, ServiceLine, InsuranceAdjustment, PatientBalance, PaymentPlan. Without consistent structure across billing system records, the chatbot retrieves a $340 balance but cannot explain whether it reflects a deductible, copay, or non-covered service — leaving patients confused and escalation rates high. Standardized claim format (837) and remittance (835) provide strong structural foundation that must be surfaced in the chatbot's response templates.

The billing chatbot needs access to patient balance data, payment plan eligibility, and payment processing — but the baseline hc-rv context confirms payer systems are 'black boxes' and RCM vendors charge for API access. L2 is the achievable state: some integrations exist (Slack bot-style access to billing balance queries), but real-time full API access across billing, payment processing, and EHR is not the baseline. The chatbot can retrieve balances and process card payments through a limited integration but cannot programmatically update payment plan terms in EHR or access insurance EOB detail.

Payment plan rules, financial assistance thresholds, and payer-specific billing policies change periodically but not on a fixed schedule. The baseline hc-rv context confirms 'payer-specific rules drift constantly without systematic tracking.' For the billing chatbot, scheduled periodic review (quarterly) of approved response scripts and payment plan parameters is achievable. This is sufficient for a chatbot with human escalation as a backstop — near-real-time sync is not required when incorrect answers route to a human agent for correction.

The billing chatbot requires integration between the chat platform, billing system (patient balances), and payment processor (card capture). The baseline hc-rv context shows EHR-to-billing integration is standard and payment posting is automated via ERA — these provide the data foundation. Point-to-point integrations between chatbot, billing system, and payment gateway constitute L2. Full API-based connections to EHR, payer portals, and collections systems are not required for the chatbot's core use cases.