Protected health information is guarded by concrete, named mechanisms — Row-Level Security on every table, a hash-chained PHI audit, TOTP multi-factor authentication, and organization-level isolation — not by a compliance badge.
PatientTrac describes what the platform actually enforces, not what it is certified to be. Every safeguard below is a specific control in the shared clinical data layer that carries across all seven connected applications. Founded in 1998, the platform was rebuilt cloud-native so these controls live in the data spine itself — not bolted on per app.
PatientTrac is built for the people responsible for protecting patient data — from security and privacy through practice administration.
Every control below is enforced in the shared clinical data layer. Nothing is bolted on.
Access rules are enforced in the database itself, so a user only ever sees the rows their organization and role permit.
Every access to protected health information is written to a tamper-evident, hash-chained audit trail.
Strong authentication and least-privilege roles govern who reaches the record.
Each practice's data is isolated at the organization level, even on shared infrastructure.
Patient-rights workflows are built in, so disclosures are tracked and can be accounted for.
Standards-based export keeps the record portable and the patient's data movable.
The safeguards above are shared across the network, but several surface as named, regulated workflows inside specific applications. Here is where they live and what they do.
Fulfilling a records request is a tracked, audited workflow — not an email with an attachment.
In ASC — the ambulatory surgery center application — controlled substances are tracked in an append-only ledger built to DEA recordkeeping requirements.
Who can reach a resource, and where secrets live, are both defined explicitly.
The record can leave in standard formats, so patients and successors are never locked in.
Because every application reads and writes the same clinical record bound by one encounter_id, these safeguards are enforced once — in the shared data layer — and apply everywhere the record travels.
Row-Level Security, tenant isolation, and the PHI audit live in the data spine every app queries — not re-implemented application by application.
Learn moreAccess rules follow the same universal encounter_id that links scheduling, documentation, and billing across specialties.
Learn moreAI runs server-side with keys never exposed to the browser, and its access to PHI is audited like any other.
Learn moreWe describe the specific controls the platform enforces. We do not claim to be a substitute for your organization's own compliance program.
Row-Level Security on every table, a hash-chained PHI audit, TOTP multi-factor authentication, server-side keys, organization-level tenant isolation, Release-of-Information with accounting-of-disclosures, C-CDA generation, EHI export, and medication reconciliation.
These are implemented safeguards, described as mechanisms rather than as a certification or a guarantee.
As a covered entity, your practice configures roles, manages users, and operates its own policies and training; PatientTrac provides the technical safeguards and enters into a Business Associate Agreement.
We support your compliance obligations with concrete controls; we do not remove them, and we describe safeguards rather than compliance status.
Many vendors answer security questions with a logo wall and a single label. PatientTrac answers with mechanisms you can inspect: Row-Level Security on every table, a tamper-evident hash-chained PHI audit, TOTP multi-factor authentication, server-side keys, and organization-level isolation — carried through the shared clinical spine that connects every app. Founded in 1998 and rebuilt cloud-native, the platform puts these controls in the data layer itself and describes them honestly, as safeguards rather than certifications.
Walk your security and compliance stakeholders through the controls, the audit model, and the Business Associate Agreement.