Alleva runs your chart.
VProGo runs everything else.
Alleva is the EMR your clinical team uses. VProGo bidirectionally syncs with Alleva and runs the operations layer above it — billing intelligence, multi-facility roll-up, patient engagement, prediction. No EMR migration, no double-entry.
What lives where
The complementary split, grounded in our shipping Alleva integration (`lib/alleva/v2/`) and Alleva's public product surface. Alleva owns the chart; VProGo owns the layer above.
= partial / add-on / requires a third-party tool ·= not in current product surface as of 2026-05.
How the Alleva integration works
Three concrete things our bidirectional Alleva sync delivers, grounded in shipping code.
Bidirectional sync, canonical layer in front
lib/alleva/v2 ships full bidirectional integration: encounters, patient master, insurance + authorizations, clinical diagnoses/orders/LOC transitions, appointments, observations, care team, and discharge summaries. Everything flows into our canonical schema so consumers (census, billing, alumni) read one shape regardless of EMR. Your Alleva chart stays untouched; the canonical layer is what powers the cross-facility dashboards.
Billing intelligence Alleva's billing modules don't reach
vProGo's RM Hub pulls Alleva attendance + signatures into compliance gates that catch unsigned-note slippage as ranked action items — not stale counters. The clearinghouse layer routes claims, processes ERAs, surfaces denials with plain-language CARC translation, and drills back to the Alleva clinical event that justified the claim.
Discharges fire vProMove the same day
When Alleva fires a discharge event, vProMove enrollment runs automatically via the canonical bridge. Recovery check-ins, peer community, surveys, and a direct thread to the alumni coordinator start the day the patient leaves treatment — not weeks later.
See the Alleva + VProGo stack
30-minute demo on a live Alleva-connected facility. We'll show the data flowing both directions and walk through what VProGo layers on top.