SecurityBuilt for patient data

Serious about privacy β€” honest about our stage.

Clinru handles names, visits, and clinical notes for real patients. We design for HIPAA-aligned US clinics from day one. We are in early access: some controls below are live today, others are on the roadmap and noted explicitly.

Encryption in transit & at rest

All traffic uses HTTPS (TLS). Patient data is stored in encrypted database infrastructure; we are extending field-level encryption for clinical fields as the product matures.

  • TLS on every browser and API connection
  • Encrypted database volumes at the host layer
  • No patient data in client-side analytics or ad pixels

Tenant isolation

Each clinic is a separate tenant. Application queries are scoped by clinic, with Postgres row-level security as a backstop so one clinic cannot read another's rows.

  • clinic_id on every tenant-scoped record
  • Row-level security policies in Postgres
  • Separate credentials per environment (dev/staging/prod)

Audit logging

Sensitive actions β€” viewing or changing patient records, exports, role changes β€” are logged with who, when, and what changed. Clinic owners can review activity for their practice.

  • Append-only audit events for patient data access
  • Export and delete actions logged explicitly
  • Support access logged separately (see below)

Least-privilege roles

Reception, doctors, and owners see different surfaces. Clinru staff do not browse clinics casually; support access requires approval and is visible to you when used.

  • Role-based access (owner, reception, doctor)
  • Support impersonation with a visible banner (when enabled)
  • Short-lived support sessions

Backups & recovery

We take regular encrypted backups and test restore procedures. Targets improve as we move from early access to general availability.

  • Automated database backups with retention
  • Restore drills on a regular cadence
  • Incident communication within 72 hours if data is affected

Your data, your control

Export patients and visits to CSV. Cancel and your data is retained for a defined period so you can migrate or reactivate, then deleted on request.

  • Self-serve CSV export
  • Deletion available on request after account closure
  • We do not sell patient data or use it for advertising
Compliance & roadmap

What we target for US independent clinics.

Certifications and integrations take time. We list status plainly so you can evaluate us for a pilot without guessing.

HIPAA-aligned designBuilt for US clinic workflows Β· BAA for pilot partners
Tenant isolationPer-clinic separation in application + database
SOC 2 Type IIOn roadmap as we scale past early access
Penetration testingThird-party tests scheduled before GA
State HIE / eRxIntegrations on product roadmap
Status pagePublic uptime reporting β€” coming soon
Architecture

How the system is shaped.

stack.txt
Edge      Β· CDN + WAF
Web       Β· Next.js (marketing + app shell)
Mobile    Β· Patient & doctor apps (iOS / Android)
API       Β· REST API with OpenAPI
DB        Β· PostgreSQL, tenant-scoped queries + RLS
Jobs      Β· Queue for reminders, exports, notifications
Storage   Β· Object storage with signed URLs for attachments
Availability

Best-effort during early access

We monitor uptime and publish a status page before general availability.

Data residency

US-first hosting

Designed for US clinic data residency expectations. Ask us about BAA before go-live.

Questions

Security FAQ on request

We share a plain-language security overview for pilot clinics and their counsel.

Our principles

How we make decisions about your data.

01 β€” Minimum

We collect the minimum data necessary to deliver the product.

No advertising trackers on the marketing site. In the product, we store what scheduling, records, and messaging require β€” not a shadow profile for resale.

02 β€” Yours

Your data is yours.

Export to CSV when you need it. If you leave, we keep data for a limited window so you can migrate, then delete on schedule unless law requires retention.

03 β€” No AI training

We do not train general models on your patient charts.

If we ship assistive features (e.g. dictation), they will be opt-in, scoped to the request, and documented in release notes.

04 β€” Transparent

If we access your data for support, you should know.

Approved support sessions use impersonation with a clear banner. Those sessions are logged like any other sensitive access.

05 β€” Honest

We say what is live and what is planned.

This page describes our direction and current capabilities. Ask us for a security FAQ or BAA before piloting β€” we would rather under-promise than over-promise.

⚑

Report a security issue

If you believe you have found a vulnerability, email us with steps to reproduce. We respond to good-faith reports as quickly as we can during early access.

Evaluate us before you pilot.

Start a 14-day trial, or contact us for a security FAQ and BAA discussion.