Privacy Policy

1. Information We Collect

Website Visitors

When you visit healthclaw.io or interact with this demo application, we may collect:

• Standard web server logs (IP address, browser type, referring URL, pages visited, timestamp)
• Aggregate, anonymized usage statistics

We do not use third-party behavioral tracking or advertising cookies.

Self-Hosted / API Users

If you deploy HealthClaw Guardrails yourself:

• All data remains on your own infrastructure. We never receive it.
• Audit events, tenant records, and FHIR resources are stored in your database (SQLite by default, PostgreSQL in production).
• You control all retention, access, and deletion policies.

Demo Submissions

API calls made against the public demo endpoint at /r6/fhir/* are ephemeral and stored transiently in the demo database. Do not submit real patient data to the public demo.

2. How We Use Information

Information collected is used solely to:

• Operate and improve the HealthClaw Guardrails service and documentation
• Diagnose errors and monitor uptime
• Respond to support inquiries submitted via GitHub Issues or email

We do not sell, rent, or share personal information with third parties for commercial purposes.

3. PHI Handling & Guardrails

HealthClaw Guardrails is designed with PHI minimization as a core architectural principle:

• PHI redaction on all read paths — names truncated to initials, full identifiers masked, addresses stripped, birth dates truncated to year, photos removed
• Audit trail — all resource access is logged with tenant, agent identity, and timestamp; no PHI in log entries
• Step-up authorization — write operations require HMAC-signed tokens in addition to tenant credentials
• Human-in-the-loop — clinical writes are blocked until a human operator explicitly confirms
• Tenant isolation — every database query is scoped to the requested tenant at the query layer, so cross-tenant access is blocked. For hosted deployments handling real records, tenant reads can additionally be authenticated with tenant-bound tokens; this is a capability the deployment enables through configuration, not a guarantee that every read on every deployment is authenticated.

These controls are reference implementations. Organizations deploying this software for production use with real patients must conduct their own risk assessment, engage qualified legal counsel, and satisfy all applicable regulatory requirements (HIPAA, HITECH, state privacy laws, etc.).

Reference Implementation vs. Production

HealthClaw is a reference implementation of guardrail patterns for AI-agent access to health data. The guardrails described above — PHI redaction, append-only audit, step-up authorization, and tenant isolation — are active in the software. The public demo runs synthetic or patient-directed data and is not a hardened multi-tenant PHI service. Production deployments are expected to add tenant-authenticated reads, BAA-covered infrastructure, and the organization's own operational and regulatory controls on top of these patterns.

4. Data Storage & Retention

Public Demo

Data submitted to the public demo may be retained for up to 30 days for debugging purposes, then deleted. No backups are made of demo data. Do not submit real PHI to the public demo.

Self-Hosted Deployments

You control all retention. The software does not phone home. No data leaves your infrastructure unless you configure an upstream FHIR server or external service.

5. Third-Party Services

The software may connect to the following external services, depending on configuration:

• FHIR servers — HAPI FHIR, SMART Health IT, Epic Sandbox, or any FHIR R4/R5 server you configure. Subject to their own terms.
• NLM Clinical Tables API — used by Curatr for ICD-10-CM code validation. No PHI is sent; only code values.
• HL7 tx.fhir.org — used by Curatr for SNOMED CT / LOINC validation. No PHI is sent; only code values.
• NLM RxNav API — used by Curatr for RxNorm drug code validation. No PHI is sent; only code values.
• Fasten Health — if the Fasten Connect integration is enabled, patient-authorized FHIR exports flow through Fasten's infrastructure. Subject to Fasten's Privacy Policy.
• Redis — used for session management and rate limiting when configured. Data remains within your infrastructure.

Upstream FHIR server URLs are never exposed to end users (URL rewriting is enforced by the proxy layer).

6. Messaging Platforms (Telegram, Slack, Discord)

HealthClaw can deliver health information over consumer messaging platforms such as Telegram, Slack, and Discord. These are consumer communication channels, not BAA-covered transport, and we do not treat them as secure medical channels.

We operate these channels under a patient-directed access posture: the patient is retrieving their own records to a channel they have chosen. Under HIPAA's individual right of access, an individual may request delivery of their own health information over an unsecured channel after being warned of the risk. In this flow HealthClaw acts as the patient's agent retrieving their own data — not as a covered entity making a disclosure to a third party.

To reduce exposure on these channels, HealthClaw applies several mitigations:

• PHI redaction on reads — the same redaction applied to all read paths (initials, masked identifiers, stripped addresses, year-only birth dates).
• PHI-free notifications — push notifications carry only counts, status, and tenant identifiers, never names, identifiers, or clinical values.
• Optional summary-only mode — responses can be limited to summaries rather than full record content.

To be candid about the trade-off: messaging-app transport combined with HealthClaw's guardrails (redaction, audit, step-up authorization, and data minimization) exceeds the security posture of typical consumer health apps, which routinely move full records over similar channels without these controls. It is still not a substitute for BAA-covered transport where a covered entity is making a disclosure.

7. Cookies & Analytics

The public demo site uses only session cookies required for Flask operation. No advertising cookies, third-party trackers, or behavioral analytics are used. Server-side access logs are the only analytics collected and are not shared with any third party.

8. Your Rights

If you have submitted data through the public demo and wish to request deletion, contact us at privacy@healthclaw.io. We will respond within 30 days.

For self-hosted deployments, all rights (access, deletion, portability) are exercised directly against your own database. We have no access to your data.

9. Children's Privacy

This software and website are intended for healthcare developers and technologists. We do not knowingly collect personal information from children under 13. If you believe a child has submitted personal information through the demo, contact us at privacy@healthclaw.io.

10. Security

We implement reasonable technical safeguards including HTTPS for all public endpoints, HMAC-signed write tokens, append-only audit logs, and tenant-scoped queries (with optional tenant-bound token authentication on reads, enabled per deployment). No system is perfectly secure. Please report security vulnerabilities via GitHub Security Advisories or security@healthclaw.io.

11. Changes to This Policy

We may update this policy as the software evolves. Material changes will be noted in the project release notes and this page will reflect the updated effective date. Continued use of the service after changes constitutes acceptance of the revised policy.

12. Contact

Privacy questions: privacy@healthclaw.io
Security disclosures: security@healthclaw.io
General: healthclaw.io
GitHub Issues: aks129/HealthClawGuardrails