Skip to content

Security

Isolation first, then everything else

A billing company's data is its own. UniPractice enforces that in the request, in every query, and in the database itself. This page says exactly what is built, and what we finish before any real patient record enters the system.

Tenant isolation

Three layers between one company's data and another's

Each layer would be enough on a good day. Together they mean a bug in one layer does not become a leak.

  1. 01

    Request context

    Every request carries a JWT. The guard loads the user, their role and their practice grants before any service runs. Everything after that works from those facts.

  2. 02

    Query scoping

    Every service filters by tenant and by the practices the user may see. Writes check practice access before they touch a row.

  3. 03

    Row-level security

    PostgreSQL row-level security is on for every tenant table. The tenant is set per transaction, so a query that forgets its filter still returns nothing from another company.

Tenant

Summit Medical Billing

Tenant admin Biller Practice manager Provider Read-only

Practice

Northside Family Medicine

Locations
2
Providers
4
Patients
3,120

Practice

Lakeview Orthopedics

Locations
1
Providers
6
Patients
2,480

Practice

Harbor Pediatrics

Locations
3
Providers
5
Patients
4,905

Every row carries its tenant and practice. PostgreSQL row-level security enforces it below the application, as a backstop if a query ever misses its filter.

Controls

What is built today

Each item below is in the product today and can be shown in a demo.

Sign-in and two-factor

Email and password with bcrypt hashing, JWT sessions, and optional time-based one-time passcodes (TOTP) as a second factor.

Roles and practice grants

Platform admin, Tenant admin, Biller, Practice manager, Provider and Read-only. Only Tenant admin, Biller and Practice manager can write. Grants limit a user to named practices.

Field-level encryption

Sensitive fields are encrypted in the database, on top of the isolation above.

Audit trail

Logins and changes are logged with who, what and when. Every claim transition is recorded as an event, so a claim can always explain its own history.

Data integrity

Money is stored as integer cents and dates as YYYY-MM-DD. Balances are calculated from the ledger, never stored, so totals reconcile to the penny.

Jobs and health

Submissions, polling and statement runs are background jobs with three retries and exponential backoff. A health endpoint and a System Health page show their state.

Secrets are never committed to the code repository, and development and demos run on fake data only.

Before any real patient data

Our gate for protected health information

UniPractice is built and demonstrated on fictitious data and is not yet ready for protected health information (PHI). We have not yet completed a HIPAA security risk analysis, signed Business Associate Agreements (BAAs) or completed a SOC 2 audit. Every item below is completed before a single real patient record enters a customer's workspace.

  1. 01

    Business Associate Agreements with every vendor that touches PHI: hosting, database, backups, email, clearinghouse and error tracking.

  2. 02

    HIPAA-eligible hosting with encryption at rest and in transit.

  3. 03

    A HIPAA security risk analysis, with written policies for access, incident response, backup and retention.

  4. 04

    Audit-log retention turned on and reviewed, with alerts for unusual access and a documented break-glass procedure.

  5. 05

    Two-factor authentication enforced for every user, with a password policy and session timeouts.

  6. 06

    PHI scrubbed from application logs and error reports.

  7. 07

    A third-party penetration test, with the findings fixed.

  8. 08

    A master services agreement plus a BAA signed with each billing company.

CPT descriptions and X12 implementation guides are licensed separately. The licensing position for both is confirmed before production use, and each customer imports its own licensed CPT descriptions.

Responsible disclosure

If you believe you have found a security problem in UniPractice, email us before you share it anywhere else. Describe what you found and how to reproduce it. Please do not access data that is not yours, and do not disrupt the service. We will acknowledge your report, keep you informed while we fix it, and credit you if you wish.

hello@unipractice.com

See UniPractice with your own workflow

A 30-minute walkthrough on demo data: charge entry to claim, submission to remit, denial to appeal. Bring your questions about your hardest payer.