1. The Zero-Knowledge Cryptographic Blueprint

All data within the secure application classified as Protected Health Information (PHI)—including medication lists, dosages, compliance logs, symptom severities, flare triggers, and free-text personal notes—undergoes mathematical obfuscation before exiting the local client runtime.

1.1 Key Derivation Function (KDF)

The server never sees, handles, or stores the user’s Master Passphrase. Instead:

• Algorithm: The client device utilizes PBKDF2 (or Argon2id) to derive a symmetric cryptographic key.
• Salt: A cryptographically secure, pseudo-random salt is generated locally upon registration.
• Key Generation: The KDF converts the passphrase and salt into a highly secure 256-bit Key Encryption Key (KEK).
• Storage Perimeter: On native mobile (iOS/Android), the KEK is moved into the hardware-backed Secure Enclave or Keystore via expo-secure-store. On the web, the KEK lives strictly within volatile execution memory (RAM) and is fully expunged the moment the browser tab is closed.

1.2 Symmetric Encryption (AES-256-GCM)

The client application serializes local relational database records into structured JSON payloads. This text is encrypted using Advanced Encryption Standard in Galois/Counter Mode (AES-256-GCM).

• Initialization Vector (IV): Every single write transaction generates a unique, cryptographically secure 12-byte random nonce (IV). This ensures that identical health entries logged at different times yield completely different ciphertext strings.
• Authentication Tag: A 16-byte GCM authentication tag is generated with each encryption cycle. This allows the client app to instantly detect if an adversary or a compromised database server has tampered with the payload during storage or transit.

2. Server-Side Data Storage & Separation of Concerns

Our hosting infrastructure on InterServer runs a standard WordPress/MySQL stack. To eliminate data exposure risks within shared cloud environments, we enforce a strict separation between user identities and user health records.

[Plaintext Identity Data] -------> [Standard WordPress wp_users Table]
                                        (Readable by Server Admin)

[Encrypted Health Payload] ------> [Custom Blind wp_patient_blobs Table]
                                        (Scrambled Ciphertext Only)

• The Blind Core Table: Encrypted payloads are pushed via an authenticated WordPress REST API endpoint to a custom table. The server maps incoming writes to the current wp_user_id but stores only the following unreadable primitives:
  • ciphertext (Opaque binary/base64 LONGBLOB string)
  • iv (Initialization Vector byte array)
  • auth_tag (Authentication Tag byte array)
• Zero-Knowledge Visibility: Because the MySQL backend holds no keys, it operates purely as a blind file-hosting platform. If a server breach occurs, the malicious actor obtains nothing but un-decryptable, cryptographically useless strings of text.

3. Local Analytics & Processing Boundaries

Traditional medical software offloads processing and data modeling to external machine learning API arrays. The Complex Patient retains 100% of the computational burden within the user’s localized physical hardware.

• On-Device Analytics: Chronological medication-to-symptom pattern analysis, lag-time mapping, and flare correlation engines execute entirely inside the client memory sandbox. No telemetry arrays or diagnostic parameters are transmitted to external computing nodes.
• Native Document Generation: When compiling “Physician Reports,” the application translates the decrypted local state directly into a structured PDF document using native on-device rendering frameworks. The document is built locally in the device’s volatile sandbox memory and is never routed through a server-side print system.

4. Age Restriction & Compliance Guardrails

Because the app platform relies on unrecoverable, client-side encryption keys and handles deeply sensitive medical logs, strict operational boundaries are enforced.

• Age Mandate (16+): Users must be at least 16 years of age to initialize a cryptographic vault on this platform. This constraint aligns with global compliance frameworks (including GDPR Article 8, California Consumer Privacy Act variations, and mobile app store distribution ecosystem policies) regarding the independent legal capacity to consent to digital data processing without parental proxy management.
• Unrecoverable Data Clause: Because our system architecture is genuinely zero-knowledge, The Complex Patient administration holds no capacity to reset user vaults, retrieve forgotten master passphrases, or recover lost health data. If a user permanently loses their passphrase and their localized offline backups, the data is mathematically lost.