Security Architecture
Platform: appeals.remedy.support
Our commitment in plain terms
You are being asked to share your name, date of birth, insurance IDs, and medical records with a platform you may have just discovered. This page explains exactly how that information is stored, who can access it, and what we have built to make sure it cannot be misused. We have written this for both technical and non-technical readers.
1. Principle: Separate Identity from Claim Data
The core architectural decision we made is this: your personal identity and your claim data are stored in completely separate, isolated systems that never directly communicate with each other. No single system holds both. A compromise of the claim pipeline exposes no personal information. A compromise of the identity vault exposes no claim data.
2. The Tokenized Split Security Model
When your information enters our platform, it is immediately split into two distinct destinations before anything is written to any database.
[ USER PORTAL / API ] (appeals.remedy.support)
|
v
[ SECURE TOKENIZATION ENGINE ]
/ \
/ \
v v
[ COLD VAULT LAYER ] [ OPERATIONAL LAYER ]
(vault_patients) (operational_cases)
* Real Legal Identity * Tokenized case_token only
* DOB & Member/Group IDs * Anonymized CPT/ICD Codes
* Digital Signature (PNG) * Carrier & Claim Metadata
* Encrypted in browser before * HIPAA & LPOA consent record
leaving your device * Accessible to AI pipeline
* No client read access ever * No PII field names permitted
A. The Cold Vault (vault_patients)
The Cold Vault stores your personal information: your full legal name, date of birth, Member ID, Group ID, phone number, email address, and drawn signature.
All of this is encrypted in your browser before it leaves your device using hybrid encryption: AES-256-GCM encrypts the payload, and RSA-OAEP encrypts the AES key. The RSA private key never leaves our server. Firebase never receives your plaintext personal information.
No browser client can read from this collection under any circumstance. Access is restricted to our internal automation systems, which operate under a separate, more restrictive layer of cloud-level access control than what governs the rest of the platform.
All data is additionally encrypted at rest by Google Cloud KMS using AES-256. Our automation does not pass vault data to any AI system.
B. The Operational Layer (operational_cases)
The Operational Layer contains only anonymized, tokenized case data. Your name, date of birth, insurance IDs, phone number, and email address do not exist here. Firestore security rules enforce this: any write attempt that includes a plaintext PII field name is rejected by the database before it is stored.
Cases are referenced by a case_token, a one-way derived identifier that cannot be reversed to reveal your identity and cannot be guessed.
This is the layer our AI systems interact with. Even in the event of an operational system compromise, no personal identity or protected health information is exposed.
3. Client-Side Browser Security
Your personal information — name, date of birth, insurance IDs, signature — is never written to your browser's local storage or session storage at any point. It is collected in Step 2 of the intake form and encrypted in your browser before it is written to any database in Step 3, after you have signed the HIPAA Authorization.
We do use sessionStorage for two non-sensitive purposes: a random UUID that isolates your file upload folder from other concurrent sessions, and your claim information (carrier, CPT codes, denial reason) so a browser refresh does not erase your in-progress form. Neither contains personal information.
The case tracker uses a one-time SMS verification code to confirm your identity. No authentication token or session credential is written to your browser after verification.
4. Authorization and Consent Records
When you complete the HIPAA Authorization and Limited Power of Attorney in Step 3, the following fields are written to your case record in the Operational Layer:
We record a confirmation that you authorized HIPAA disclosure, a confirmation that you granted Limited Power of Attorney, the exact timestamp of your confirmation, and the version of the authorization text you agreed to.
Your drawn signature is stored as a PNG file in isolated cloud storage alongside any supporting documents you upload. The file path is recorded in your case record so it can be retrieved when building your appeal packet.
These records are enforced at the database level — a case cannot be created without valid, complete authorization on file. Your authorization is not merely implied by the existence of a signature file; it is recorded as a discrete, timestamped, versioned fact.
5. Transport and Infrastructure Security
All connections to appeals.remedy.support are served over TLS 1.3 via Firebase Hosting. The following HTTP security headers are applied to every response:
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
All files uploaded to Firebase Storage are encrypted at rest using AES-256 managed by Google Cloud KMS. No client can read any uploaded file directly. Files are accessible only to our internal systems for the purpose of preparing your appeal.
Questions about our security architecture? Visit our support page — our AI support line can answer most questions immediately. For anything that requires written follow-up, you can also reach us at compliance@remedy.support.