Connected Workflows

Five journeys, one shared record.

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.

Shared Record Cross-App Launch One encounter_id Server-Side AI Provider-Facing EN/ES/FR Revenue-Cycle Workflows
Built for

Wherever a patient moves between hands.

The journeys matter most where care crosses schedulers, specialists, procedures, billing, and follow-up — inside one group or one clinic.

Multi-specialty medical groups
Ambulatory surgery centers
Aesthetic & cosmetic surgery practices
Behavioral & neurobehavioral health
Perioperative & procedural teams
Practices unifying intake, care & billing
The five journeys

Five paths, one clinical spine.

Each flow names the apps at every stage and the single encounter_id that carries the record from the first step to the last.

02

Cosmetic consult → Proposal → Surgery → Recovery

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, ASC, and Companion.

How it connects to the network

Every journey rides the same clinical spine.

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 overview
AI & Compliance Trust

Connected, but never on autopilot.

Moving a record across apps changes nothing about who decides — intelligence stays assistive and PHI stays governed by concrete mechanisms.

Server-Side AI · Clinician Review

How AI works across a journey

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.

Concrete Mechanisms

How the record stays protected in motion

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.

Why it's different

A journey, not a handoff.

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.

Walk one journey on your own patients.

Pick a specialty and we'll trace a real encounter across the connected apps — intake to billing — on one shared record.