Rezint Clinic Queue

Trust

Security

Last updated: September 2026

Operated by Rezint Tech. Rezint Clinic Queue is a product, not the company name.

Rezint Clinic Queue is a product of Rezint Tech. This page describes security controls that are implemented in the current software. It is not a certification, not “ABDM compliant” as a formal claim, and not a guarantee that any internet service is 100% secure.

Application Security

The product is a Next.js web app with Firebase Authentication, Cloud Firestore, and Firebase Storage. Client configuration uses public Firebase web keys (normal for Firebase apps). Database and Storage access is constrained by server-side security rules and signed-in user roles. Super-admin secrets and allowlists are environment configuration, not committed as source.

Authentication & Access Control

Clinic staff, partners, and Super Admin sign in with Firebase Auth (email/password). Super Admin can be limited to allowed emails, requires a device/session unlock where configured, and additional OTP / TOTP steps before sensitive admin actions. Destructive Super Admin actions can require password re-authentication.

Role-Based Access

Roles include clinic owner (main doctor), staff, partner, and Super Admin. Staff accounts receive explicit permissions (queue, staff management, branding). Firestore rules enforce clinic isolation: a clinic’s queue and patient records are not readable as another clinic’s data. Cabin / doctor desks can use additional PIN or code gates where the clinic enables them.

Data Protection

Traffic is served over HTTPS in production. Data at rest is stored in Google Cloud / Firebase services used by the project. We do not claim encryption schemes we do not operate ourselves (for example we do not claim “military-grade” encryption). Clinics should use strong passwords and share dashboard access only with trusted staff.

API Security

Most product data access is through the Firebase SDKs with authentication tokens and Firestore rules — not a public unauthenticated clinic-data API. Limited server routes exist for Super Admin device and TOTP flows and require a valid ID token plus role checks. Sandbox ABDM gateway callbacks are accepted on HTTPS server routes under /api/abdm (acknowledgement only). Super Admin can register the bridge URL. This is not ABDM certification and not production health-information exchange.

Audit Logging

The product records operational activity used to run the clinic (for example queue actions, daily stats, and last-active timestamps). This is operational history, not a full security SIEM. Super Admin outreach and lead status changes are stored for operations.

Backup & Recovery

Primary data lives in Firebase/Google Cloud. We rely on that platform’s durability and on our own ability to restore from project-level backups where enabled in the Google Cloud / Firebase console. Clinics should keep a simple paper or local fallback for rare outages. We do not promise a specific RPO/RTO.

Vulnerability Management

Application dependencies are tracked in this repository and updated as part of normal maintenance. We do not claim a named bug-bounty program or a scheduled external audit unless one is actually completed and listed here.

Security Testing

We test features in development and staging before release. Formal penetration-test or WASA/ISO certificates are not claimed on this page.

Incident Response

Report suspected security issues using the contact details below. We will investigate, contain access where we can (for example disabling accounts or tightening rules), and notify affected clinic operators when we have a clear, confirmed impact. There is no implied government incident desk.

Related: ABDM Integration · Privacy Policy

Contact / grievance

Rezint Tech — use these official details for privacy requests, security reports, and general business contact. Do not send patient health records to this mailbox unless a clinic has a lawful reason and we have asked for them.