Security Features¶
Quill Medical takes security seriously. This page explains the security features built into the frontend application to protect patient data and ensure safe communication.
Authentication & Access Control¶
Secure Login¶
How it works¶
- Username and password required
- Passwords are never stored in plain text
- Failed login attempts are limited
- Automatic logout after inactivity
Why it matters¶
Ensures only authorized users can access patient information and clinical data.
Two-Factor Authentication (2FA)¶
What it is¶
An extra layer of security requiring a second form of verification beyond your password.
How to use¶
- Enable in Settings → Security
- Scan QR code with authenticator app (like Google Authenticator or Authy)
- Enter the 6-digit code when logging in
Required for¶
- All clinic staff (mandatory)
- Recommended for patients (optional but encouraged)
Benefits¶
Even if someone obtains your password, they cannot access your account without your authentication device.
Automatic Session Management¶
Session Timeout¶
- Access tokens expire 15 minutes after issuance (not after inactivity)
- The API client automatically refreshes tokens on 401 responses
- If refresh fails (e.g. refresh token expired after 7 days), you are redirected to login
Token Refresh¶
- Access tokens are short-lived (15 minutes)
- Automatically refreshed via the 7-day refresh token when a request returns 401
- Seamless experience without repeated logins
Why this is important¶
Prevents unauthorized access if you step away from your device without logging out.
Permission-Based Access Control¶
Architecture overview¶
Quill Medical implements a defence-in-depth security architecture for access control, with multiple layers of protection:
Backend (source of truth)¶
- All permissions validated server-side
- Every API request verified
- No trust of client-side state
- Enforcement of role-based access rules
Frontend (user experience)¶
- Hides inaccessible features from UI
- Prevents confusion and failed requests
- Clear navigation based on permissions
- Graceful handling of unauthorized access
Permission levels¶
The system uses a hierarchical permission model:
- Patient (lowest privileges)
- Access to own health information
- View assigned clinical letters
- Message assigned clinicians
-
Update own contact details
-
Staff
- All patient privileges
- Access to assigned patient records
- Create clinical letters
-
Messaging capabilities
-
Admin
- All staff privileges
- User management
- Patient administration
-
System configuration
-
Superadmin (highest privileges)
- All admin privileges
- Full system access
- Security settings
- Audit log access
Tiered security approach¶
Different user types receive different experiences when attempting unauthorized access:
Patients¶
- Show 404 "Not found" page
- No indication that feature exists
- Prevents information disclosure
- Security through obscurity for patient-facing features
Staff and administrators¶
- Show 404 "Not found" page by default
- Can be configured to redirect to home with
fallback=\"redirect\" - Consistent behaviour across all unauthorized access attempts
Implementation¶
The permission system uses the RequirePermission component to protect routes:
<RequirePermission level="admin">
<AdminDashboard />
</RequirePermission>
Behaviour¶
- Checks user's permission level on route access
- Compares against required permission level
- Shows loading state during authentication check
- Redirects or shows 404 based on user type
Security features¶
- No premature rendering of protected content
- Automatic redirect for unauthenticated users
- Permission checks on every route navigation
- Consistent enforcement across application
Defence in depth¶
The permission system follows security best practices:
Multiple validation layers¶
- Frontend route guards (UX)
- Backend API authentication (enforcement)
- Database-level access controls (data protection)
- Audit logging (accountability)
Fail-safe defaults¶
- Deny access by default
- Explicit permission grants required
- No implicit privilege escalation
- Conservative error handling
Information disclosure prevention¶
- Patient users see minimal error information
- No enumeration of existing features
- Generic error messages prevent probing
- Consistent response times
Compliance¶
This architecture supports regulatory requirements:
- ISO 27001: Access control and authentication
- NHS Digital: Role-based access control (RBAC)
- GDPR: Principle of least privilege
- Clinical safety: DCB0129/0160 access controls
Data Protection¶
Encryption in Transit¶
What happens¶
- All data transmitted between your browser and the server is encrypted
- Uses industry-standard TLS (Transport Layer Security)
- Same technology banks use for online banking
What it protects¶
- Passwords during login
- Message content
- Patient information
- Clinical letters
Visual indicator¶
Look for the padlock icon in your browser's address bar.
Encryption at Rest¶
Server-side protection¶
- All patient data stored in encrypted databases
- Healthcare-grade security standards
- Multiple layers of protection
Client-side protection¶
- Minimal data stored in browser
- Automatic clearing on logout
- No permanent storage of sensitive information
No Persistent Storage¶
What we don't store in your browser¶
- Patient health information (PHI)
- Clinical notes or letters
- Payment details
- Conversation history beyond current session
What is stored temporarily¶
- Session credentials (deleted on logout)
- User preferences (non-sensitive)
- Cache for faster loading (non-sensitive)
Privacy Features¶
Protected Health Information (PHI)¶
Commitment¶
Patient health information is never
- Displayed in browser URLs
- Stored in browser history
- Cached permanently
- Visible in browser debugging tools
- Logged to external services
Audit Logging¶
What is logged¶
- User logins and logouts
- Messages sent and received
- Letters created and viewed
- Changes to patient records
- Administrative actions
What is not logged¶
- Passwords
- Authentication codes
- Payment card details
Purpose¶
- Regulatory compliance
- Security monitoring
- Accountability
- Troubleshooting
Access¶
- Only authorized administrators can view logs
- Logs are tamper-evident
- Retained per legal requirements
Secure Communication¶
Message Security¶
End-to-end protection¶
- Messages encrypted during transmission
- Stored securely on healthcare-grade servers
- Only accessible to intended recipients
- Cannot be intercepted in transit
Access controls¶
- Patients can only see their own conversations
- Clinicians see only assigned patients
- Administrators have oversight capability
- All access is logged
Attachment Security¶
File uploads¶
- Virus scanning before storage
- File type validation
- Size limits enforced
- Secure storage separate from messages
File downloads¶
- Secure token-based access
- Time-limited download links
- Cannot be accessed without authentication
Payment Security¶
Status: Planned feature — not yet implemented.
Payment processing via Stripe is planned but not yet built. When implemented, it will follow PCI standards with no credit card details stored in our system.
Account Security¶
Password Requirements¶
Minimum standards¶
- At least 8 characters long
- Mix of letters, numbers, and symbols recommended
- Cannot be commonly used passwords
- Cannot be your username or email
Best practices¶
- Use a unique password for Quill
- Consider a password manager
- Change password if you suspect compromise
- Never share your password
Account Recovery¶
Status: Planned feature — not yet implemented.
Password reset functionality is not yet available. Contact an administrator to reset your password.
Suspicious Activity Detection¶
Status: Planned feature — not yet implemented.
Automatic monitoring of suspicious activity (failed logins, unusual locations) is planned but not yet built.
Browser Security¶
Supported Browsers¶
Recommended¶
- Chrome (latest version)
- Firefox (latest version)
- Safari (latest version)
- Edge (latest version)
Why up-to-date browsers matter¶
- Latest security patches
- Modern encryption support
- Better privacy controls
- Optimal performance
Browser Settings¶
Recommended settings¶
- Cookies: Allow for quillmedical.com
- JavaScript: Enabled
- Pop-ups: Allow for payment processing
- Auto-fill: Disable for passwords (use password manager instead)
Private/Incognito Mode¶
Considerations¶
- Can be used for extra privacy
- Session cleared immediately on close
- No browsing history saved
- May need to re-authenticate more frequently
Device Security¶
Shared Devices¶
Best practices¶
- Always log out after use
- Don't save password in browser
- Clear browser history after use
- Use private browsing mode
Not recommended¶
Using shared public computers for accessing Quill Medical due to security risks.
Mobile Devices¶
Additional considerations¶
- Enable device lock (PIN/fingerprint)
- Keep operating system updated
- Use official app stores only
- Be cautious on public Wi-Fi
Lost or Stolen Devices¶
Immediate actions¶
- Change your password from another device
- Contact clinic administrator
- Review recent account activity
- Enable 2FA if not already active
Reporting Security Issues¶
How to Report¶
If you notice¶
- Suspicious activity on your account
- Potential security vulnerability
- Unusual system behavior
- Phishing attempts
Contact¶
- Use "Report Issue" in Settings
- Email: security@quillmedical.com
- Mark as urgent if immediate threat
- Provide as much detail as possible
What Happens Next¶
Our process¶
- Immediate acknowledgment
- Investigation by security team
- Remediation if needed
- Communication of resolution
- Preventive measures implemented
Compliance & Standards¶
Regulatory Compliance¶
Standards we follow¶
- GDPR: European data protection regulation
- HIPAA: US healthcare data requirements
- ISO 27001: Information security management
- SOC 2: Service organization controls
Regular Security Testing¶
Ongoing measures¶
- Penetration testing by security experts
- Regular security audits
- Code security reviews
- Vulnerability scanning
- Third-party security assessments
Data Retention¶
Policies¶
- Data retained per legal requirements
- Automatic deletion after retention period
- Patient data export available anytime
- Complete deletion upon account closure
Your Responsibilities¶
As a User¶
Please¶
- Keep your password secure
- Enable two-factor authentication
- Log out when finished
- Report suspicious activity
- Keep contact information current
- Review account activity regularly
Never¶
- Share your credentials
- Use simple passwords
- Access from public computers if avoidable
- Save passwords in browsers
- Ignore security warnings
As Clinic Staff¶
Additional responsibilities¶
- Complete security training
- Follow data handling policies
- Report security incidents immediately
- Maintain patient confidentiality
- Use secure communication channels only
- Keep professional devices secure
Security FAQs¶
Q: Is my data stored on my device?¶
A: Only temporarily during your session. All sensitive data is cleared when you log out.
Q: Can clinic staff see all my messages?¶
A: Only your assigned clinician and necessary administrators can access your conversations.
Q: What happens if I forget to log out?¶
A: The system automatically logs you out after 15 minutes of inactivity.
Q: Is video chat secure?¶
A: Video features (when available) use encrypted connections and are not recorded without explicit consent.
Q: How do I know the site is legitimate?¶
A: Check for the padlock icon in your browser and verify the URL begins with https://.
Q: Can I use a public Wi-Fi network?¶
A: While the connection is encrypted, we recommend using private networks when possible for extra security.
Updates & Improvements¶
We continuously improve our security measures
- Regular security patches
- New security features
- Enhanced monitoring
- Updated encryption standards
- User security education
Stay informed¶
Security updates are announced via email and in-app notifications.