GDPR & KVKK Compliance

PreClear Health operates under the following frameworks. The list is illustrative — where a specific clause is binding, the controlling text is the legal instrument itself.

• Regulation (EU) 2016/679 (“GDPR”), with particular attention to Article 9 (special categories of personal data — health) and Article 32 (security of processing).
• Turkey Personal Data Protection Law No. 6698 (“KVKK”), with particular attention to Articles 5 and 6 (lawful processing of personal and special-quality data) and Article 12 (data-security obligations).
• Turkish Remote Health Services Regulation, Official Gazette dated 10 February 2022 (No. 31746), which governs the scope and limits of telemedicine consultations.
• EU AI Act (Regulation (EU) 2024/1689) — we treat our software as a high-risk AI system under Article 6 and Chapter III. Our intake agent, clinical review assistant, and document agent are operated under documented governance described in this statement.
• Medical Device Regulation (Regulation (EU) 2017/745) — our software is being developed as Medical Device Software (MDSW), intended to qualify as Class IIa under MDR. The CE technical file accrues incrementally; pre-launch we will obtain a Notified-Body conformity assessment.

PreClear Health does NOT operate under US HIPAA. Where US patients may engage our service, processing occurs under GDPR / KVKK as the applicable frameworks.

PreClear Health acts as data controller in respect of personal data processed for its own delivery of the pre-operative clearance service. Each operating clinic acts as a separate data controller for the data processed in its own clinical record after the patient arrives. PreClear Health and each operating clinic exchange data on the legal bases described in our Privacy Policy and under the Clinical Services Agreement signed before the first patient is processed.

Sub-processors operating on our instructions (cloud hosting, transactional email, payment processing, AI inference) are bound by written Data Processing Agreements that mirror Articles 28 GDPR and KVKK Article 12 obligations.

Patient personal data is stored in the European Union (Supabase Frankfurt). The primary database, audit log, biometric artifacts (Mallampati photographs, lab documents), encrypted identity records, and Vault-managed secrets all live in the Frankfurt region. Our web frontends (marketing, intake, dashboard) are served from Vercel Edge, which routes requests to the nearest edge location; sensitive operations — authentication, field encryption and decryption, identity lookups — execute against the EU Supabase store rather than at the edge.

Where transient processing outside the EU is required (for example, an AI inference call), we route to providers that offer EU-region endpoints and contractual zero-retention terms. Patient identity data is excluded from those calls; only the structured clinical content is sent, and the request is logged with a data-minimisation manifest enumerating the exact fields transmitted.

• In transit: TLS 1.2 or higher, with HSTS preloading on all customer-facing endpoints.
• At rest, application layer: AES-256-GCM with HKDF-SHA256 derivation, applied to selected patient identity fields (full name, date of birth, email, phone), to clinician identity fields (full name, email), to the referral label, and to encrypted metadata blobs on biometric artifacts. Application-layer field encryption is scoped to these identifier and PHI-capable fields; it does not imply that every clinical field or all free-text content is field-level encrypted. Clinical free-text answers are minimised and redacted by field-specific rule and stored in the clinical schema.
• At rest, database layer: Supabase-managed encryption-at-rest on Postgres and Storage.
• Key custody: production keys live in Supabase Vault. The root key is never resident in the application process. Key rotation is performed under the documented Key Rotation Runbook, with a clinical-legal committee approval reference recorded on the audit chain.
• Document signing: the PreClear Verified™ advisory bundle is signed with a JSON Web Signature (RFC 7515). The signing key is held in the same KMS family as the encryption key; the public verifier is published on our public verification endpoint.

Access to personal data is governed by a capability-based authorisation model. Each role (triage coordinator, reviewer, senior reviewer, compliance officer, clinic admin, clinic coordinator, super admin) is mapped to a documented set of capabilities. Privileges granted to a role are versioned; every JWT issued to a user carries the role’s authorization version, and any role-level change automatically invalidates issued tokens.

Privileged reads of decrypted identity data — for example, in response to an erasure request — are gated by a break-the-glass workflow that requires the actor to record a reason and the specific fields accessed. The access is logged in the immutable audit chain.

Every clinical and security-relevant action is recorded in an append-only, hash-chained audit log. Each entry references the SHA-256 of the previous entry, so tampering with a historical row breaks every subsequent hash. The audit chain is the canonical evidence trail for the CE technical file, ISO 14971 risk follow-up, and any post-incident review.

Audit-chain entries never carry plaintext personal data: IP addresses, User-Agent strings, and recipient email addresses are stored as SHA-256 hashes. The chain head is anchored through an EU-based Qualified Trust Service Provider (RFC 3161) to defend against retroactive tampering by an insider with database access. Anchoring runs on a weekly operational schedule — a scheduled job rather than a legally mandated frequency — and a missed run is caught up by the next.

AI components in our pipeline are confined to non-clinical-decision roles: structured intake, translation, document summarisation for the human reviewer, retrieval of guideline snippets. Every clinical decision (clearance, conditional clearance, decline) is taken and signed by a human consultant anesthesiologist. AI outputs land in a separate provenance store (`clinical.llm_outputs`) with a content-integrity hash; they are never written into the clinical-data tables that drive the human review. The AI provider and the exact model version are pinned at deployment time through environment configuration; a given runtime uses a single provider with no automatic cross-provider or cross-model fallback. If the provider is unavailable, the system enters an explicit degraded mode (intake paused, manual queue surfaced) rather than silently substituting another model.

Every AI prompt change is gated by an evaluation harness that runs anonymised gold-standard cases, translation-quality judges in five locales, and red-team scenarios designed to defeat role-confusion and jailbreak attempts. A prompt change cannot ship until the harness signals pass. A monthly random 5% sample of AI outputs is reviewed by senior reviewers against a four-axis rubric (accuracy, safety, completeness, clarity); aggregated results gate the next prompt-version deployment.

This list is maintained on this page. Material changes (a new sub-processor, a region change) will be announced at least thirty (30) days before they take effect, giving operating clinics time to raise objections.

Processing of special-category health data on the scale envisaged by PreClear Health triggers the DPIA obligation under GDPR Article 35 and KVKK Article 7. A DPIA covering the full intake-to-delivery pipeline is maintained in our internal regulatory record and is provided to participating clinics under non-disclosure. The DPIA is updated on every material change to processing — new sub-processors, new data categories, new AI prompts.

Patient rights described in our Privacy Policy are operationalised by:

• Self-service access: structured intake responses are visible to the patient through the patient portal during the active case.
• Erasure: a documented workflow in our compliance runbook describes how a patient erasure request is processed. Audit-chain entries that must be retained by law are flagged in the response.
• Rectification: corrections during an active case are made through the clarification loop and are reflected in the audit chain. Post-delivery rectifications are handled through the same break-the-glass workflow as privileged identity reads.
• Portability: the structured clinical record can be exported in canonical JSON form on request.
• Withdrawal of consent: at any time, the patient can email privacy@preclear.health to withdraw consent. Processing stops immediately, save for audit-chain entries retained on legal grounds.
• Right to lodge a complaint: KVKK Kurumu in Turkey; the lead supervisory authority in your country of habitual residence for EU residents.

PreClear Health maintains a documented incident-response plan. Suspected breaches are classified, contained, and investigated under the responsibility of the Compliance Officer; the Data Protection Officer assesses notification obligations under GDPR Article 33 (72-hour window to the supervisory authority) and KVKK Article 12 (notification “as soon as possible”). Affected patients are notified directly when the breach is likely to result in a high risk to their rights.

Coordinated security disclosure: security@preclear.health. Researchers acting in good faith are protected under our disclosure policy and will be acknowledged in our compliance log unless they prefer to remain anonymous.

Operating clinics may, on reasonable notice, request a review of the technical controls described above. We make our SOC 2 / ISO 27001 statements (where available), our DPIA, our sub-processor list, and the relevant sections of our CE technical file available under non-disclosure. Where on-site inspection is requested for cause, we will arrange it under the conditions set out in the Clinical Services Agreement.

Material changes to this Compliance Statement are announced at least thirty (30) days before they take effect, and the previous version is preserved on our internal regulatory record. The version-controlled change history is available on request.