Privacy Policy

HealthClaw Guardrails · healthclaw.io · Effective: March 29, 2026 · Last updated: July 4, 2026

Important: HealthClaw Guardrails is a developer tool and reference implementation. It is not a covered entity or business associate under HIPAA. When used in upstream proxy mode with real patient data, operators are responsible for their own HIPAA compliance, BAAs, and applicable regulations.

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.

Connected AI Assistants (Claude, ChatGPT, and other MCP clients)

When you connect a health data source through the hosted HealthClaw connector, we process:

  • Identity and demographic data — name, birth date, contact details (redacted before any AI model sees them)
  • Clinical data — conditions, medications, lab results, vital signs, immunizations, and documents
  • Coverage data and device/wearable observations
  • Operational data — tenant identifiers, OAuth tokens, and access logs recording who accessed what and when (access logs never contain clinical values)

Every read passes through PHI redaction before reaching an AI model; every write requires step-up authorization and explicit human confirmation. In pass-through proxy mode we store nothing — data flows from your own FHIR server through the guardrails and is not retained.

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.

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 and Controls

If you use the hosted connector (via Claude, ChatGPT, or another MCP client), you can:

  • Disconnect any data source at any time
  • Export your data as standard FHIR at any time
  • Request deletion of your tenant and all stored records — deletion completes within 30 days and is confirmed to you
  • Review the audit trail of every access to your records

We never sell your data, never use it for advertising, and never use it to train AI models.

If you have submitted data through the public demo and wish to request deletion, contact us at privacy@healthclaw.io or support@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

Terms & Conditions Back to Home