Security and Data Handling

Product data-flow summary

• Clinic account access is handled through Clerk authentication and organization management.
• Subscription and billing flows are handled through Stripe.
• Clinic records in Redis include clinic organization ID, subscription references, clinic name, branding settings, and theme settings.
• Branding uploads may be stored as image data used for clinic-facing surfaces.
• Workspace preferences are primarily stored in the user's browser local storage.
• Reports are generated from values entered in the workspace and are not intended to make SpinoLens the clinic's patient record system.
• Patient viewer links store temporary normalized atlas values, clinic branding, allowed views, timestamps, and clinic ID in server-side storage so the link can resolve later.

Patient viewer link design

• Links use bearer tokens generated with cryptographic randomness.
• Atlas values are not placed in the URL.
• The browser route uses a URL fragment, and the viewer resolves the token through a server call.
• Server storage keys are derived from a hashed token value with a server-side pepper.
• API responses for patient-share flows use no-store caching headers, no-referrer policy, and nosniff headers.
• Create, resolve, and revoke actions are rate limited.
• Patient viewer payloads expire automatically and may be revoked by the clinic.

Current subprocessors

• Clerk: authentication, sign-in, users, and clinic organization management.
• Stripe: subscription billing, checkout, customer portal, webhooks, and payment processing.
• Vercel: hosting, deployment, routing, application logs, and performance infrastructure.
• Upstash Redis: clinic configuration, subscription references, patient-share payloads, and rate-limit counters.
• Vercel Speed Insights: performance measurement for the web application.

Security controls in the current application

• Authenticated API routes for branding, billing, and patient-share creation/revocation.
• Active subscription checks before updating branding or creating patient links.
• Tokenized patient links with values resolved server-side.
• No-store headers for patient-share and internal JSON APIs.
• Rate limits on patient-share create, resolve, and revoke actions.
• Revocation support for patient viewer links.
• Automatic expiration for patient viewer links.
• Referrer policy configured at the application layout and patient-share API layer.

Clinic implementation guidance

• Use clinic-approved patient communication channels when sending patient links.
• Avoid placing patient identifiers in clinic branding, support requests, billing messages, or screenshots sent to SpinoLens.
• Treat patient viewer links like sensitive links because anyone with the token may be able to access the viewer until expiration or revocation.
• Use SpinoLens as an educational visualization tool, not as the official patient record.
• Store exported reports in the clinic's approved records system if the clinic decides to retain them.

Security contact

Report security or privacy concerns to privacy@spinolens.com.