Skip to content
Pidgeon Health/ LegalAccount

Status: Effective July 22, 2026 (counsel-reviewed 2026-07-06, no notes; declared effective by founder decision 2026-07-22). See PACKET.md.

Last updated 2026-07-22

All legal documents

Privacy Policy

Pattern Engine LLC d/b/a Pidgeon Health Status: Effective July 22, 2026 (counsel-reviewed 2026-07-06, no notes; declared effective by founder decision 2026-07-22). See PACKET.md. Effective Date: July 22, 2026

1. Overview

Pattern Engine LLC, a Kansas limited liability company, doing business as Pidgeon Health ("Pidgeon Health," "we," "us," or "our"), provides healthcare integration testing and development software: the Post, Flock, Loft, and Migrate desktop applications, the Pidgeon launcher, the open-source Post command-line tool (the "CLI"), and the account, billing, and team-management service at account.pidgeon.health (the "Account Services").

Two facts shape everything in this policy:

  1. The products run on your device. The desktop applications (the "Desktop Apps") process healthcare messages locally, backed by a local Pidgeon.Bridge engine bound to your machine's loopback interface. Generation, validation, and de-identification of healthcare messages happen on your device, not on our servers.
  2. Our cloud holds account data, not healthcare data. The Account Services store the information needed to operate your account and subscription. We do not store Protected Health Information ("PHI"), and real patient data never reaches our cloud in the ordinary operation of the products.

This policy describes the personal data we do collect, why, and your rights over it. Pattern Engine LLC d/b/a Pidgeon Health is the data controller for the personal data described in this policy.

2. Information We Collect

2.1 Account Information

When you create an account, we collect:

  • Email address
  • Name (optional)
  • Organization name
  • Password (hashed; never stored in plaintext)

2.2 Payment Information

Payment processing is handled entirely by Stripe. We do not store credit card numbers, CVVs, or other payment card data. We receive from Stripe:

  • Last four digits of your card (for display purposes)
  • Billing address
  • Subscription status and plan tier

2.3 Interface Structure Metadata ("Telemetry")

To improve vendor-specific validation profiles, message generation quality, and platform intelligence for all users, we collect de-identified interface structure metadata through the Vendor Intelligence Network ("VIN"). This data is referred to throughout this policy as "Telemetry." Whether Telemetry is collected at all depends on your tier and your consent settings (§ 2.5); the operative disclosure and consent mechanics are set out in the Telemetry & VIN Consent Notice.

What Telemetry includes:

Usage Metadata:

  • Command and feature usage patterns (which features are used, how often, in what sequence)
  • Message types and standards targeted (e.g., "ADT^A01", "HL7v2", "FHIR R4")
  • Execution performance metrics (duration, success/failure, error types)
  • Environment information (operating system, product version, integration engine type)
  • Session frequency and feature adoption patterns

Interface Structure Data:

  • Message segment types and their ordering (e.g., "MSH, PID, PV1, OBR, OBX")
  • Field population patterns: which fields within each segment are populated (boolean presence indicators, not field values)
  • Field metadata: data type, character length, component count (structural characteristics, not content)
  • Z-segment catalogs: custom segment names, field counts, and data types
  • Vendor signature metadata: sending application and facility identifiers (hashed before transmission to prevent organizational identification)

Standardized Clinical Terminology Distributions:

  • Coding system usage per field (e.g., "DG1.3 uses ICD-10-CM")
  • Code category distributions at the chapter or class level (e.g., "30% of diagnoses are circulatory, 20% respiratory") — never individual code values that could contribute to patient identification
  • Standardized clinical codes (ICD-10, LOINC, SNOMED CT, CPT, NDC, CVX) are public classification systems maintained by government and standards bodies; their presence in aggregate statistical distributions is structural information about interfaces, not patient information

De-identified Message Templates:

  • Complete message structure with patient and provider identifiers removed on your device, before transmission, using our de-identification engine
  • The engine removes the 18 HIPAA Safe Harbor identifier categories (45 CFR § 164.514(b)(2)) as they appear in standard HL7 v2, FHIR, and NCPDP message structures, with free-text edge-case scanning on the roadmap; the as-built coverage map, including its known edge-case gaps, is documented in De-Identification & HIPAA Safe Harbor
  • What is preserved: segment ordering, standardized clinical codes, field formatting patterns, vendor-specific structural elements
  • Free-text fields (clinical notes, comments) are replaced with "[REDACTED]" or, when available, processed to extract only medical terminology (condition names, medication names, procedure names) while stripping identifying entities

Validation Results:

  • Which validation rules passed or failed, on which segment and field combinations
  • Failure patterns by message type and vendor profile
  • Custom validation rules added by users (rule definitions only, not the data validated against)

What Telemetry NEVER includes:

  • Patient names, medical record numbers, Social Security numbers, dates of birth, addresses, phone numbers, or other direct identifiers targeted by the de-identification engine
  • The actual content of healthcare message fields (we collect structural metadata — that a field is populated and its data type — not what the field contains)
  • Your organization's name or facility identifiers in readable form (facility identifiers are cryptographically hashed before transmission)
  • Geographic data below the state level
  • Free-text clinical notes in their original form
  • Any data from Teams or Enterprise tier installations unless your administrator has explicitly enabled telemetry sharing
  • Any data from the free CLI (all telemetry is off in the free CLI; § 2.5)
  • Any data from on-premises or air-gapped deployments (telemetry is disabled at the architecture level; no egress endpoint is configured)

As defense-in-depth, an independent server-side scan runs on all Telemetry on receipt and replaces any residual identifier patterns before storage. This backstop supplements — it does not replace — the on-device de-identification that is the primary control.

2.4 Product Usage Analytics

Separate from the Telemetry in § 2.3, we use product usage analytics (via PostHog) to understand how the marketing site and the Desktop Apps are used ("Usage Analytics"):

  • Page views and navigation patterns (marketing site)
  • Feature and screen usage events from the Desktop Apps (event names, counts, durations, tiers — never message content or patient data)
  • Referral sources
  • Device type and browser (anonymized)
  • Geographic region (country-level only)

Desktop-app usage events are emitted through the local Pidgeon.Bridge and forwarded to the analytics sink only when telemetry consent is enabled (§ 2.5); on-premises and air-gapped installs disable forwarding at the architecture level so nothing egresses. Events are restricted to a typed allowlist — an event not on the allowlist cannot be transmitted — and event properties are bounded values that cannot carry message bodies. This Usage Analytics stream is a distinct pipeline from the Vendor Intelligence Network corpus in § 2.3: different payloads, different destinations, and separately controllable. (See VIN Aggregation & Egress § 2.)

2.5 Telemetry Controls and Tier Defaults

You have granular control over both pipelines:

Control How to Access Effect
Disable all telemetry CLI: pidgeon config telemetry --off / Desktop Apps: Settings → Privacy Nothing is collected or transmitted, in either pipeline
Metadata only CLI: pidgeon config telemetry --level metadata Only usage patterns and environment info (no interface structure or templates)
Structure only CLI: pidgeon config telemetry --level structure Usage patterns and interface structure (no de-identified templates)
Full CLI: pidgeon config telemetry --level full All Telemetry categories
View what's collected CLI: pidgeon config telemetry --show / Settings → Privacy → View Data See examples of each category and current settings
Audit recent transmissions CLI: pidgeon config telemetry --audit / Settings → Privacy → Audit Log Review what was transmitted and what was stripped by the de-identification layer

Tier defaults:

  • CLI (free, open source): All telemetry is off in both pipelines. The free CLI transmits nothing.
  • Console Free: Telemetry categories enabled by default — this is the disclosed value exchange for free access to the full desktop experience, and it is presented to you at first run (see the Telemetry & VIN Consent Notice). You may reduce or disable collection; disabling all telemetry may adjust access to Console-Free-specific features. Exception — EU/UK users: telemetry is OFF by default and requires explicit opt-in (see § 10); the full product is provided either way.
  • Pro / Individual: Telemetry enabled by default; full opt-out available with no feature restriction.
  • Teams / Enterprise: ALL telemetry disabled by default. Zero data leaves your network unless your administrator explicitly enables sharing. This default is a contractual commitment in Enterprise agreements.
  • On-premises / air-gapped: telemetry is off at the architecture level; no egress endpoint exists to send to.

Your tier is resolved server-side when consent state is evaluated; a client cannot raise its own collection level by misreporting its tier.

2.6 Healthcare Messages

The Desktop Apps run on your own machine, backed by the local Pidgeon.Bridge engine on localhost. If you input healthcare messages for generation, validation, de-identification, monitoring, or migration:

  • Messages are processed on your device by the local engine. Validation, generation, and de-identification do not transmit message content to our servers.
  • De-identification runs entirely on-device before any data leaves your machine. PHI is removed using our Safe Harbor-based methodology with synthetic replacement (SafeHarborPlus). The engine removes the 18 HIPAA Safe Harbor identifier categories as they appear in standard HL7 v2, FHIR, and NCPDP message structures, with free-text edge-case scanning on the roadmap; see De-Identification & HIPAA Safe Harbor for the requirement and the as-built coverage map.
  • Message content is not stored on our servers unless you explicitly sync a workspace to the cloud. Where cloud workspace sync is offered, data is stored in Supabase (PostgreSQL) with row-level security and encryption at rest.
  • Loft monitors live healthcare interfaces locally: message content never leaves your network, full alert detail stays in the local review queue, and only a redacted alert payload (rule identifier, severity, message type, timestamp, counts, file identifiers — never field values or message bodies) is sent to the alert destinations you configure.
  • The only healthcare-derived data that may leave your device is de-identified Vendor Intelligence Network Telemetry, and only when consent is enabled for your tier (§ 2.3, § 2.5). Its egress path is documented in VIN Aggregation & Egress.

2.7 Support and Communications

If you contact support, we collect the contents of your message and any attachments you choose to send. Do not include PHI in support communications; our Acceptable Use Policy prohibits it and our support tooling is not designed to receive it.

3. How We Use Your Information — and Our Lawful Bases

We use collected information to:

Purpose Data Lawful basis (GDPR/UK GDPR, where applicable)
Provide and maintain the products and Account Services Account information, subscription state Contract (Art. 6(1)(b))
Process payments and manage subscriptions Payment information (§ 2.2) Contract (Art. 6(1)(b)); legal obligation for tax/financial records (Art. 6(1)(c))
Send transactional emails (verification, password reset, receipts) Email address Contract (Art. 6(1)(b))
Send product updates and onboarding guidance (opt-out available) Email address Legitimate interests (Art. 6(1)(f)); consent where required
Detect and prevent fraud, abuse, and security incidents Account and request metadata Legitimate interests (Art. 6(1)(f))
Improve the products through Usage Analytics (§ 2.4) Usage events Consent (Art. 6(1)(a)) for EU/UK users; legitimate interests elsewhere
Build aggregated vendor intelligence profiles from Telemetry (§ 2.3) De-identified Telemetry Consent (Art. 6(1)(a)) for EU/UK users; disclosed value exchange with opt-out per § 2.5 elsewhere
Respond to support requests Support communications Contract / legitimate interests

Vendor intelligence aggregation rules:

  • Telemetry is aggregated into anonymized vendor intelligence profiles that improve validation accuracy and message generation quality for all users.
  • Aggregated interface patterns are published only when at least 50 independent sessions have contributed data for a given vendor and message type, preventing organizational identification.
  • Updated vendor profiles are distributed to users via the pidgeon data update mechanism.

We do not:

  • Sell your personal information, or share it for cross-context behavioral advertising
  • Use your data for advertising
  • Train AI models on your healthcare messages
  • Share individual usage data with other customers
  • Publish or distribute Telemetry in any form that could identify an individual user, patient, or organization
  • Retain raw Telemetry events beyond 12 months (aggregated statistical summaries are retained)
  • Collect any telemetry from Teams or Enterprise installations without explicit administrator opt-in, or from the free CLI at all

4. Third-Party Services

We use the following service providers to operate the platform. Each processes data on our behalf under its own terms and our data-protection commitments (see also our public Subprocessor List):

Service Purpose Data Shared Privacy Policy
Stripe Payment processing Email, billing address, payment method https://stripe.com/privacy
Supabase Authentication, account/billing database, cloud workspace sync, and de-identified Vendor Intelligence Network ingest (§ 2.3) Account data, optionally-synced workspace data, de-identified Telemetry https://supabase.com/privacy
Vercel Hosting for the marketing site and the Account Services web application Request metadata (IP address, pages requested) https://vercel.com/legal/privacy-policy
Cloudflare CDN, security, and DNS for our web surfaces; software download delivery (R2 object storage behind downloads.pidgeon.health) IP address, request metadata https://cloudflare.com/privacy
PostHog Product Usage Analytics (§ 2.4) — feature/screen events, no message content Anonymized usage events, device/region metadata https://posthog.com/privacy
Sentry Error tracking Error context (PII stripped), device info https://sentry.io/privacy

The Desktop Apps run on your device against a local engine; healthcare message processing does not occur on our cloud infrastructure (§ 2.6). The services above handle account, billing, analytics, de-identified Telemetry, software delivery, and (where enabled) cloud workspace sync — not message-level PHI.

5. Data Retention

Data Type Retention Period Notes
Account information Until account deletion + 30 days 30-day grace period for reactivation
Payment records 7 years Legal/tax compliance requirement
Usage metrics 90 days Aggregated for billing and analytics
Workspace data Until deletion by user You control your workspace lifecycle
Usage Analytics data 24 months Anonymized, no PII
Error logs 90 days PII stripped before storage
Telemetry events (raw) 12 months Auto-archived, then deleted; aggregated statistics retained
Vendor intelligence profiles (aggregated) Indefinite Statistical summaries only — no individual-level data
De-identified message templates 12 months (raw) Aggregated into vendor patterns, then raw templates deleted
Support communications 24 months after resolution For quality and continuity

Post-termination, account data is retained for a 30-day export window and then deleted, except where the table above states a longer legally required period.

6. Data Security

We implement industry-standard security measures:

  • Encryption in transit (TLS 1.2+) and at rest
  • Row-level security (RLS) for tenant data isolation in the Account Services database
  • API key hashing before storage
  • JWT-based authentication with configurable token expiry
  • The local Bridge engine binds to the loopback interface by default and requires an authentication token
  • Cloudflare WAF for application-layer protection; rate limiting per subscription tier
  • Signed release artifacts and signature-verified updates
  • Regular dependency vulnerability scanning

No system is perfectly secure; § 8 of the Terms of Service describes our liability terms, and our incident-response process governs how we notify affected users of a breach.

7. HIPAA Considerations

Pidgeon Health provides testing and development tools and is not a covered entity under HIPAA. In the ordinary operation of the products, we do not create, receive, maintain, or transmit PHI on behalf of any covered entity: message processing happens on your device, and our cloud holds account data only.

For our users who work in healthcare environments:

  • Our de-identification tools implement a Safe Harbor-based methodology, on-device (§ 2.6)
  • Our synthetic data generation eliminates the need for real PHI in testing
  • Message content processed for validation is handled locally and is not transmitted to our servers
  • Our position on Business Associate Agreements — including the narrow BAA we make available when your procurement process requires one — is set out in the No-BAA Architecture Statement and BAA template

7.1 Telemetry and HIPAA

Telemetry is de-identified on your device before transmission using our de-identification engine, which removes the 18 HIPAA Safe Harbor identifier categories (45 CFR § 164.514(b)(2)) as they appear in standard HL7 v2, FHIR, and NCPDP message structures, with free-text edge-case scanning on the roadmap. The de-identification requirement, the as-built coverage of the 18 Safe Harbor identifier categories, and known edge-case gaps are documented in full in De-Identification & HIPAA Safe Harbor. The engine is the same one we provide as a product feature (Post de-identification).

Additionally, an independent PHI-pattern scan runs server-side on all Telemetry on receipt, providing defense-in-depth against accidental identifier inclusion.

Standardized clinical terminology codes (ICD-10, LOINC, SNOMED CT, CPT, NDC, CVX) are public classification systems; their inclusion in aggregate statistical distributions describes interface structure, not individuals.

8. Your Rights

Depending on your jurisdiction, you may have the right to:

  • Access: request a copy of the personal data we hold about you
  • Correction: request correction of inaccurate personal data
  • Deletion: request deletion of your account and associated personal data
  • Portability: request your data in a structured, machine-readable format
  • Restriction and objection: restrict or object to certain processing
  • Withdraw consent: where processing is based on consent (including telemetry), withdraw it at any time with effect going forward (§ 2.5)
  • Opt out: unsubscribe from non-transactional communications

To exercise these rights, contact privacy@pidgeon.health. We will respond within the time required by applicable law. You will not be discriminated against for exercising your rights.

EU/UK users additionally have the right to lodge a complaint with your supervisory authority (in the UK, the Information Commissioner's Office).

California residents (CCPA/CPRA): the categories of personal information we collect are described in § 2 (identifiers, commercial information, internet activity); the purposes in § 3; the recipients in § 4. We do not sell personal information and do not share it for cross-context behavioral advertising, and we have not done so in the preceding 12 months. We do not use or disclose sensitive personal information for purposes requiring a right to limit. You may exercise access, deletion, correction, and portability rights via privacy@pidgeon.health; you may designate an authorized agent to act for you.

9. Children's Privacy

The products and services are business tools and are not directed to children under 16. We do not knowingly collect personal information from children. If we learn that we have collected data from a child under 16, we will delete it promptly.

10. International Data Transfers

The Desktop Apps run locally on your device. Our cloud surfaces — account, billing, analytics, de-identified Telemetry ingest, software downloads, and any cloud workspace sync — are hosted in the United States.

If you use these cloud surfaces from outside the United States, the associated account and analytics data is transferred to and processed in the United States. For transfers of EU/UK personal data to the United States, we rely on the European Commission's Standard Contractual Clauses (and the UK Addendum / International Data Transfer Agreement, as applicable) with our service providers, as described in our Data Processing Addendum, together with supplementary technical measures (encryption in transit and at rest).

For EU/UK users, Vendor Intelligence Network telemetry and product Usage Analytics are off by default and require explicit opt-in (§ 2.5); consent is requested through the Telemetry & VIN Consent Notice and may be withdrawn at any time.

11. Changes to This Policy

We may update this Privacy Policy from time to time. Material changes will be communicated via email or in-app notification at least 30 days before taking effect. The version and date at the top reflect the most recent revision.

12. Contact

For privacy-related questions or requests:

If you are in the EU or UK, you may also contact us at privacy@pidgeon.health to reach the contact point for GDPR matters.