Data & Security
What Claim Harbor stores — and what it is not built for.
This page describes only behavior that is implemented in the product today.
Data scope
De-identified summary metrics only.
Claim Harbor is designed for de-identified summary revenue-cycle metrics and is not intended for Protected Health Information (PHI). Users should not enter patient names, dates of birth, MRNs, member IDs, claim-level patient identifiers, or other PHI.
What you enter
Period-level totals such as charges, payments, contractual adjustments, total A/R, A/R over 90 days, claims submitted, denied claims, and clean claim rate — plus the organization, practice, and provider names you choose to record.
What Claim Harbor does not collect
No claim files, no remittance files, no patient records, and no payer connections. There is no automated ingestion from your billing systems.
Implemented controls
Controls in place today.
The following describes the current implementation. Nothing below implies a certification or audit.
- User authentication is handled through the existing Supabase Auth implementation, including email/password sign-in and password reset.
- Database access uses the existing verified Row Level Security policies, so workspace records are isolated to the account that owns them.
- Payments use the existing Stripe checkout and customer portal implementation.
- Claim Harbor does not store full payment-card numbers.
Claims we do not make
What we are not asserting.
Claim Harbor does not claim HIPAA compliance. It does not claim SOC 2, HITRUST, or PCI certification, independent penetration testing, or any specific encryption standard beyond what the underlying hosted platforms provide. If any of those are independently established in the future, this page will be updated to state exactly what was verified and when.
Because Claim Harbor is intended for de-identified summary metrics, the appropriate control is what you enter: keep patient-level identifiers out of the workspace.