Security & Compliance
RxRescue's security & compliance posture.
RxRescue is medication inventory software. It's designed not to collect PHI, which means it sits outside HIPAA-covered scope by design — but that's a starting point for security thinking, not a substitute for it. This page documents the architecture, the controls in place, and the things customers and procurement teams should know before deploying.
What data RxRescue stores
For every bottle the pharmacy scans, RxRescue stores: GTIN (the manufacturer's GS1 product identifier), lot number, serial number (when present), expiration date, drug name, dose, package size, the scan timestamp, and the originating device and user identifier. For every change to inventory state — pulls, edits, quarantines, reversions — RxRescue stores the operation type, the affected bottle ID, the operator, the timestamp, and any operator-provided note.
For the account itself: the pharmacy name, the contact email, the Stripe customer and subscription identifiers (so we can charge and email you), and the setup code (a 6–7 character pharmacy join token).
What RxRescue does not store: patient names, patient identifiers, prescription numbers, prescriber names, dates of birth, bed/cell assignments, regimens, dispense events tied to a patient, or any other patient-shaped identifiers.
Why this is outside HIPAA scope by design
HIPAA's Privacy Rule applies to Protected Health Information (PHI) — information that identifies an individual and relates to their health, healthcare, or healthcare payment. RxRescue's data model is built around bottles, not patients. The app rejects patient-shaped imports at the column-name level: a CSV or Excel paste that contains columns matching common PHI patterns (MRN, patient name, DOB, etc.) is blocked before any data is persisted.
This is a deliberate design choice, not a regulatory conclusion. "Designed not to collect PHI" is what we control. Whether your facility's specific deployment of RxRescue (combined with your other systems and your operational practices) is itself outside HIPAA scope is a determination your facility's privacy officer needs to make in writing. We can support that determination with the architectural detail on this page; we can't make it for you.
If your facility requires a Business Associate Agreement (BAA) despite the no-PHI design, contact security@rxrescue.us — we'll work with your compliance team to provide whatever documentation makes the review tractable.
How sync works
RxRescue uses a sync-event architecture. Each device maintains its own local SQLite database (encrypted on Android via SQLCipher; encrypted-at-rest on Windows via the OS). User actions — scans, edits, pulls, quarantines, reversions, imports — are recorded as sync operations. Each operation is a small structured record: operation type, target bottle ID, timestamp, the change being made, and the originating device's logical clock.
Operations are appended to a server-side log (the delta_log table in our hosted Supabase project). Other devices joined to the same pharmacy pull the log periodically and apply operations they haven't seen. The log is the transport, not the system of record — each device replays operations into its own local DB.
Because the log is durable, a lost device's history can be recovered onto a replacement device by re-syncing from the pharmacy's setup code.
Authentication and device access
Each pharmacy has a setup code (6–7 chars) that authorizes a device to join. The setup code is delivered by email after trial signup completes via Stripe; it's not displayed on the welcome page. A device that has the setup code is treated as a bearer credential by the sync transport — comparable to an API key.
Compensating controls that the pharmacy is responsible for: device-level encryption (enabled by default on modern Android and Windows), screen-lock policies, removing devices from the pharmacy's device list when staff turnover happens (currently a support-assisted action — write to support@rxrescue.us and we'll revoke the device's join authorization). A self-serve revocation UI is on the product roadmap; tracked at audit item #67 (2026-05-13 audit pass).
The setup code can be rotated at any time. Rotation invalidates the code immediately for any new device join. Devices already joined with the prior code are not automatically revoked by rotation — that's a deliberate behavior so a code rotation doesn't kick the pharmacy's working devices off-line. To revoke a specific already-joined device, contact support.
Where data is stored
The hosted sync transport runs on Supabase, hosted on Amazon Web Services. The project is located in US-East. Data in transit uses TLS 1.2+. Data at rest in Supabase is encrypted with AES-256.
Billing is handled by Stripe. We never see or store credit card numbers — Stripe holds them. The Stripe customer ID and subscription ID are stored in our Supabase project so we can reconcile webhooks against the right pharmacy account.
Trial-signup emails (the setup-code delivery email) are sent via Resend. The email is composed server-side and sent immediately on Stripe webhook event; we don't retain a copy of the message body after sending.
The application itself (Windows installer, Android APK) is hosted on GitHub Releases. The site at rxrescue.us is hosted on Vercel.
Audit log and retention
Every state-changing operation in RxRescue is recorded in the audit log: who, what, when, and the prior + new value for the changed field. The audit log is exportable as CSV at any time from the in-app Reports menu. It carries operator identifiers and timestamps but no patient identifiers.
Local audit-log retention defaults to 7 years (DSCSA requires 6 years; we keep an extra year as safety margin). Older records can be exported and pruned from the device. The server-side sync log retains operations long enough to support peer recovery; older records are tombstoned and pruned by automated maintenance.
Application hardening
- Encrypted local database on Android (SQLCipher); OS-level encryption on Windows.
- No PHI fields are rendered, captured, or accepted via import.
- Honeypot + rate limiting on the trial signup and lead-capture forms; per-IP throttling caps signup abuse.
- Content Security Policy in report-only mode on rxrescue.us as of May 2026; transition to enforce mode after a one-week observation window.
- HSTS enabled with includeSubDomains and preload directives.
- FDA recall checking against the openFDA recall feed daily; matching bottles flagged in-app within 24 hours of recall publication.
- Mandatory-update enforcement if a build is published with a known data-integrity issue (red banner, non-dismissible).
Vendor security review materials
For procurement and IT review, we can provide:
- This page in document form (PDF)
- The hosted-services list above with each vendor's compliance posture (Supabase SOC 2, Stripe PCI DSS Level 1, AWS, etc.)
- Sample audit-log CSV showing the data shape
- The Privacy Policy at rxrescue.us/privacy
- End User License Agreement (delivered with the software)
Email security@rxrescue.us with the specific questionnaire your team uses and we'll fill it in.
Security contact
security@rxrescue.us — for vulnerability reports, vendor security review questions, BAA inquiries, and incident-response coordination.
For day-to-day support (lost device, suspected unauthorized access, etc.) use support@rxrescue.us.
Last updated 2026-05-13.