How we protect your data.

Current status

Owed currently works with synthetic data only. We are not accepting live patient data while we complete counsel review, policy approval, workforce training, an incident-response exercise and an independent security review. Remittances marked as production are rejected. Our AWS business associate agreement is active. Customer agreements must be signed before any patient data is accepted.

The controls below describe the customer application. Our public demo runs separately with fictional records and supplied sample files. Its anonymous workspaces expire after 30 minutes; it does not send appeals, deliver real invitations or connect to outside SFTP servers. The demo is not an environment for patient data.

Agreement before data

A signed business associate agreement (BAA) is required with each customer before any protected health information (PHI) is shared. When the customer is a billing company, Owed acts as its subcontractor business associate. We must verify that the customer's agreements with its practices permit the service and disclosure to Owed, including any required subcontractor approval. For programs covered by 42 CFR Part 2, the applicable agreement terms are also subject to counsel review before onboarding. Our development and test systems refuse remittances marked as production.

Our infrastructure runs on Amazon Web Services and is covered by the AWS Business Associate Addendum. Every AWS service that stores or processes patient data is on AWS's list of HIPAA-eligible services. Eligibility and an AWS BAA do not by themselves establish Owed's HIPAA compliance.

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, application logs and audit trail use an AWS KMS key that Owed controls and rotates yearly. Other service logs are encrypted at rest.
• 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. Those fields remain encrypted in a database-only copy.
• Automatic imports: SFTP connection details and credentials are field-encrypted too. Owed checks the server's pinned SSH key before reading files and leaves the source files in place. Saved credentials are never returned to the browser or included in exports or logs.

Access

• Every customer user 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 for 15 minutes.
• 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 through a restricted database role, with policies that limit queries to the active organization. These controls add a database-level check alongside application permissions.

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, the customer environment records AWS management API activity through CloudTrail in write-once storage that no one, including us, can delete for six years.

Minimum necessary

Owed asks only for the data it needs to find what payers owe. Reports leave out patient names and member IDs and truncate claim numbers, and each one is recorded with an ID printed on every page. The one exception is the complete export an owner can take of their own data, for example when leaving; it's recorded the same way. Our application logs never contain request bodies, remittance content or decrypted fields.

Infrastructure

• The application and database run in AWS US East, Ohio, in a production account dedicated to customer data. Contract reading uses Amazon Bedrock across US regions only.
• 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, plus daily copies retained for 30 days using AWS Backup Vault Lock. We've tested a full restore.
• Even our own administrators can't turn off audit logging or threat detection, or delete encryption keys, secrets or backups, without a separate emergency procedure that is itself logged.
• Infrastructure defined as code; container images are scanned for vulnerabilities, and a deploy stops on any critical finding.

AI

Claude Sonnet 4.6 on Amazon Bedrock reads fee schedules from contract PDFs through a US-only inference profile. Every rate goes through checks and then your review before it is saved. Contract uploads must not contain patient information.

Payment findings use deterministic rules, and supported appeal letters come from fixed templates. You review and send the letters yourself. Contract PDFs and reader results are held temporarily in application memory. Bedrock's data-protection documentation describes model processing; Owed does not use customer data to train models.

Our commitments before real PHI

Our risk analysis and security, privacy and incident-response policies are drafted and awaiting review and approval. Before live PHI, we must finish those reviews, train everyone with production access, exercise incident response, complete an independent security review and move incoming business email to a BAA-covered mailbox. We do not hold a SOC 2 report. HHS does not recognize private HIPAA certifications as proof of compliance.

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.