Privacy Policy

1. Who we are

AZREX (“AZREX”, “we”, “us”) is a software service that helps specialty medical practices draft insurance appeal letters grounded in payer medical policy. We are headquartered in the United States and our infrastructure runs in AWS us-east-1.

For privacy questions, contact support@azrex.us.

2. Scope of this policy

This policy describes how we handle information for three audiences:

• Visitors to our marketing site (azrex.us): basic analytics, contact form submissions.
• Pilot users at sandbox practices invited to walk through the product on synthetic data.
• Future production customers: how we will handle PHI once a BAA is in place. Production processing is not yet available.

3. Posture on Protected Health Information (PHI)

AZREX is not currently authorized to receive PHI. Our acceptable-use policy and terms of service prohibit pilot users from uploading real patient data; all walkthroughs run on synthetic documents we provide or that the customer constructs from de-identified data.

Once our §6 production gate is met and a BAA is executed with a customer, AZREX will operate as a Business Associate under HIPAA (45 CFR §§ 160, 164) with respect to that customer’s PHI. PHI handling will then be governed by the BAA and by this policy as updated for production.

4. What we collect

Account and contact data

When a practice is provisioned, we store: tenant slug and display name, user email address, user role (practice user or practice admin), and per-user bearer token metadata (prefix and hashed secret — never the plaintext secret).

Uploaded documents (sandbox only)

During a walkthrough, sandbox users may upload synthetic denial letter PDFs. AZREX validates the file, extracts structured fields, generates a draft appeal, and persists the document, denial record, and appeal under that tenant’s isolated namespace. Files uploaded outside of synthetic-data parameters are out of scope and are not authorized.

Operational telemetry

Structured logs and Prometheus metrics for service operation: request paths, HTTP status, latency, authentication outcomes, and audit-log write counts. Logs are gated by an allow-listed redactor to prevent PHI-shaped values from leaking; values that match PHI-like patterns are dropped before persistence.

Audit log

Every authenticated request that touches a record produces a row in an append-only, HMAC-chained audit log. Audit rows contain actor, tenant, action, and timestamp; they do not contain document contents.

Marketing site analytics

The marketing site uses minimal first-party analytics (page views, referrer, country-level geo) and does not employ third-party advertising trackers.

5. How we use it

• To provide the AZREX service to the practice that uploaded the document.
• To produce an audit trail that the practice can export for compliance.
• To operate and secure the service (rate limiting, abuse detection, incident response).
• To respond to support requests sent to support@azrex.us.

We do not sell or rent any data, we do not train machine-learning models on customer documents, and we do not share customer data with third parties for marketing purposes.

6. Subprocessors

We use a small set of vetted subprocessors. Production subprocessors will be enumerated in each customer’s Data Processing Addendum. Current and planned subprocessors:

• Vercel— hosting for the marketing site and the Backend-for-Frontend (BFF). No PHI flows through Vercel-side code paths; tokens are kept server-side.
• Cloudflare— DNS, Cloudflare Tunnel, and Cloudflare Access in front of the AZREX backend.
• Amazon Web Services (AWS) — planned in us-east-1 (RDS, ECS, S3, Secrets Manager, CloudWatch, KMS, CloudTrail). Engagement contingent on AWS BAA execution.
• Anthropic via Amazon Bedrock — planned, feature-flagged OFF. Used only when the regex path cannot confidently extract a field; will run inside the AWS BAA scope.
• Observability vendor — pending (CloudWatch, Datadog, or Grafana Cloud, decision contingent on BAA terms).

We will give customers reasonable advance notice of material subprocessor changes via the customer email address on file.

7. Security posture

• Per-tenant data isolation enforced by automatic ORM query scoping and PostgreSQL Row-Level Security.
• Bearer tokens hashed with Argon2id; plaintext secrets shown to the issuer once and never persisted.
• Two-pass PHI redaction in the structured logger; PHI-shape detection in audit-log details.
• Append-only audit log with HMAC chain, sequence numbers, and external checkpoint anchors.
• Backend has no public IP; reachable only through Cloudflare Tunnel + Cloudflare Access Service Token.
• OpenTelemetry traces and Prometheus metrics carry no PHI; labels are bounded.
• Encryption in transit (TLS 1.2+). Encryption at rest will be enforced via AWS KMS in production.

8. Retention

Sandbox tenants are ephemeral and are purged when a walkthrough concludes or after 90 days of inactivity, whichever comes first. Production retention will be defined per customer in the Data Processing Addendum; default proposal is 7 years for PHI-bearing records to match HIPAA documentation requirements, with shorter retention on telemetry.

9. Your rights under HIPAA and applicable state law

When AZREX processes PHI as a Business Associate, individuals retain the rights granted by the HIPAA Privacy Rule (45 CFR § 164.500 et seq.) through their healthcare provider as the Covered Entity. Requests to access, amend, or restrict use of PHI should be made through the provider that uploaded the document. We will cooperate with the provider to fulfill validated requests.

For non-PHI account data, contact support@azrex.us to access, correct, or delete it.

10. Children

AZREX is a B2B service for licensed healthcare providers. The marketing site is not directed at children and we do not knowingly collect personal information from children under 13.

11. International transfers

AZREX infrastructure is located in the United States (us-east-1). We do not currently offer the service outside the United States. International data transfer mechanisms are not in scope for this version of the policy.

12. Changes to this policy

We will post material changes to this page and, where required, notify customers via the contact email on file at least 30 days before the change takes effect. The “Effective” date at the top reflects the most recent revision.

13. Contact

AZREX — support@azrex.us