Security & Compliance

Safeguards you can point to.

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.

RLS-Isolated Hash-Chained Audit TOTP MFA Server-Side Keys Org-Isolated EN/ES/FR
Built for

Controls your compliance team can review.

PatientTrac is built for the people responsible for protecting patient data — from security and privacy through practice administration.

Compliance & privacy officers
Information-security teams
Practice administrators
Multi-specialty & multi-site groups
Ambulatory surgery centers
Practices modernizing a legacy EMR
The Mechanisms

Six concrete controls, in the data layer.

Every control below is enforced in the shared clinical data layer. Nothing is bolted on.

01

Row-Level Security on every table

Access rules are enforced in the database itself, so a user only ever sees the rows their organization and role permit.

  • RLS policies applied to every table holding clinical or PHI data
  • Enforcement at the data layer, not only the application UI
  • Scoped by organization and role on every query
  • The same policy set protects all connected apps
02

Hash-chained PHI audit logging

Every access to protected health information is written to a tamper-evident, hash-chained audit trail.

  • Each audit entry is chained to the hash of the prior entry
  • Reads and writes of PHI are recorded, not just logins
  • Altering or deleting a past entry breaks the chain and is detectable
  • Supports internal review and accounting-of-disclosures workflows
03

Authentication & access control

Strong authentication and least-privilege roles govern who reaches the record.

  • TOTP multi-factor authentication for provider accounts
  • Role-based access aligned to job function
  • Model and integration API keys remain server-side, never in the browser
  • Sessions and privileges scoped per organization
04

Organization-level multi-tenant isolation

Each practice's data is isolated at the organization level, even on shared infrastructure.

  • Every record is bound to an owning organization
  • Cross-organization access is denied by default at the data layer
  • Multiple locations run under one tenant without co-mingling other practices' data
  • Isolation travels with the shared record across every app
05

Release of Information & accounting of disclosures

Patient-rights workflows are built in, so disclosures are tracked and can be accounted for.

  • Release-of-Information (ROI) request handling
  • Accounting-of-disclosures record for PHI shared externally
  • Disclosure events tie back to the audited PHI trail
  • Supports responding to patient access and disclosure requests
06

Interoperability & portability

Standards-based export keeps the record portable and the patient's data movable.

  • C-CDA generation for standards-based clinical document exchange
  • Electronic Health Information (EHI) export for portability
  • Medication reconciliation across encounters and sources
  • Portability built on the same shared record, not a separate copy
How it connects

One data spine, one set of controls.

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.

Shared data layer

Row-Level Security, tenant isolation, and the PHI audit live in the data spine every app queries — not re-implemented application by application.

Learn more
The encounter_id key

Access rules follow the same universal encounter_id that links scheduling, documentation, and billing across specialties.

Learn more
Server-side AI

AI runs server-side with keys never exposed to the browser, and its access to PHI is audited like any other.

Learn more
How we talk about compliance

Safeguards, not certifications.

We describe the specific controls the platform enforces. We do not claim to be a substitute for your organization's own compliance program.

Concrete Mechanisms

What the platform enforces

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.

Shared Responsibility

Where your program fits

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.

Why it's different

Named controls, plainly stated.

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.

Review the safeguards with your team.

Walk your security and compliance stakeholders through the controls, the audit model, and the Business Associate Agreement.