How we protect your data.

Agreement before data

We sign a business associate agreement (BAA) with every customer before any protected health information (PHI) is shared, and we handle PHI only as that agreement allows. For programs covered by 42 CFR Part 2, we also agree to qualified service organization terms. Until a BAA is in place, we work only with synthetic data: our own development and test systems refuse files marked as production.

Our infrastructure runs on Amazon Web Services, using only services on AWS's list of HIPAA-eligible services, and is covered by AWS's business associate addendum before any PHI arrives.

Encryption

• In transit: TLS 1.2 or newer with modern ciphers, HTTPS enforced with HSTS, and verified TLS between the application and the database.
• At rest: the database, backups, secrets, logs and audit trail are encrypted with a customer-managed AWS KMS key that rotates yearly.
• In the application: patient names, member IDs, patient control numbers and the raw remittance files are encrypted again with AES-256-GCM before they reach the database, so a database copy alone doesn't reveal patients.

Access

• Everyone signs in with a password and a time-based authenticator code. There is no way to turn multi-factor authentication off.
• Accounts are created only by invitation from an owner or admin, each for a named person. There are no shared logins.
• Roles (owner, admin, biller, viewer) limit what each person can see and do, and are checked on every request.
• Sessions end after 15 minutes idle and 12 hours in total. Five wrong passwords lock the account.
• Patient identifiers are masked by default; revealing one is a deliberate action that is recorded.

Isolation

Each customer's data is separated inside the database by row-level security. The application reaches customer data only through a restricted database role that can see one organization at a time, so a bug in application code can't return another customer's rows.

Audit trail

An append-only audit log records every view of patient data, every reveal of an identifier, every export and every change: who, what and when. Entries are chained with cryptographic hashes and protected by database triggers, so they can't be edited or removed without detection. The log itself never contains patient information. Separately, every administrative action in our AWS accounts is recorded in write-once storage kept for six years.

Minimum necessary

Owed asks only for the data it needs to find what payers owe. Exports leave out patient names and member IDs and truncate claim numbers, and each export is recorded with an ID printed on every page. Our application logs never contain request bodies, remittance content or decrypted fields.

Infrastructure

• Hosted in a single US region (AWS US East, Ohio), in a production account dedicated to customer data.
• A web application firewall in front of the application, and continuous threat detection across the account.
• Point-in-time database recovery for 35 days, with deletion protection.
• Infrastructure defined as code; container images are scanned for vulnerabilities and deployed only if they pass.

AI

Whether money is owed is decided by deterministic rules, never by a model. If we add AI-drafted appeal letters, drafting will run through Amazon Bedrock under the AWS BAA, a person will review and sign every letter, and your data will never be used to train a model.

Our commitments before real PHI

Before we accept the first real remittance, we complete a documented HIPAA risk analysis, written security and privacy policies, workforce training, an incident-response exercise, a tested database restore and an independent security review. We don't claim certifications we don't hold: there is no official HIPAA certification, and a SOC 2 report is on our roadmap.

Reporting a vulnerability

If you believe you've found a security issue, email security@owed.health. We respond promptly and won't pursue good-faith research that avoids privacy violations and service disruption. Our security.txt has the details.