A patient rarely stays in one app — so PatientTrac binds every stage of the visit to a single, universal encounter_id that moves with the patient across purpose-built specialty applications.
Each journey below names the applications involved and the shared encounter_id that ties the stages together. Because every app reads and writes the same patient and encounter records, a journey stays one record instead of becoming a chain of copies. Founded in 1998, PatientTrac was rebuilt cloud-native around exactly this shared clinical spine.
The journeys matter most where care crosses schedulers, specialists, procedures, billing, and follow-up — inside one group or one clinic.
Each flow names the apps at every stage and the single encounter_id that carries the record from the first step to the last.
The everyday office visit: a pre-visit questionnaire becomes the encounter, the visit is documented, and the same encounter drives the claim.
Profiler intake, the Forge visit, and billing all move on one shared encounter_id — no re-keyed charts.
The aesthetic path: a consult becomes a proposal, the procedure runs in the surgery center, and recovery is monitored — all on one record.
Consult, proposal, surgery, and recovery stay tied to one shared encounter_id across Revela, PatientTrac Ambulatory, and Companion.
The behavioral path: intake precedes the evaluation, standardized scales sit alongside the note, and follow-up closes the loop.
Profiler, Mind, and Companion share one encounter_id from intake through follow-up.
The procedural episode: the ambulatory case opens, perioperative documentation covers the whole episode, and recovery is monitored after discharge.
The ambulatory case, the Continuum operative record, and Companion recovery all write to one shared encounter_id.
The revenue spine: Forge schedules the visit and issues the encounter, cross-app launch carries it into the specialty, and documentation returns for claims.
One encounter_id issued in Forge follows the cross-app launch and returns for claims — no duplicate entry.
The stages differ by specialty, but the record does not: one patient, one encounter, one audit trail.
Whatever path a patient takes — intake to billing, consult to recovery, scheduling to claims — each app reads and writes the same patient and encounter records on one secure data layer, governed by Row-Level Security and a tamper-evident, hash-chained PHI audit. The shared encounter_id is what makes a journey a single record instead of a chain of copies, and cross-app launch carries the patient and encounter with the clinician between specialty apps.
Explore the platform overviewMoving a record across apps changes nothing about who decides — intelligence stays assistive and PHI stays governed by concrete mechanisms.
AI-assisted summaries, drafts, alerts, and suggestions for clinician review; API keys remain server-side; clinical decisions remain with licensed professionals.
Patient-facing AI in Companion is non-diagnostic and non-prescriptive, grounded in the care plan, routes patients to the care team, and directs emergencies to local services.
Row-Level Security on every table, a hash-chained PHI audit, TOTP multi-factor authentication, server-side keys, organization-level tenant isolation, ROI and accounting-of-disclosures, C-CDA generation, and EHI export.
Revenue-cycle workflows support standards-based claim generation (X12 837P), ERA/835 posting, and documentation completeness; they support billing workflows and do not guarantee reimbursement.
In most systems, moving a patient between specialties means re-keying the chart, faxing a summary, or losing context at every boundary. On PatientTrac, each of these five journeys is a single record: purpose-built apps sit on one clinical spine, bound by one encounter_id, with server-side AI and concrete compliance mechanisms woven through — multilingual, multi-site, and multi-specialty from the first step to the last. Founded in 1998, it was rebuilt cloud-native for exactly this.
Pick a specialty and we'll trace a real encounter across the connected apps — intake to billing — on one shared record.