Security & Privacy
TheatreLink is designed with security at its core. Here is how we protect your data.
Encryption in Transit
All data transmitted between your browser and our servers is encrypted using TLS 1.3, the latest and most secure transport protocol. No data is ever sent in plaintext.
Encryption at Rest
All data stored in our database is encrypted at rest using AES-256 encryption, the industry standard for healthcare data protection.
Australian Data Residency
All TheatreLink data is stored in AWS Sydney (ap-southeast-2). Your data never leaves Australia, meeting Australian Privacy Act requirements for health-related information.
Multi-Factor Authentication
All user accounts support MFA via authenticator apps (TOTP) and biometric authentication (WebAuthn/FaceID). MFA can be enforced at the hospital level.
Role-Based Access Control
Every user is assigned a specific role (Theatre Manager, Surgeon, Practice Manager, etc.) with access strictly limited to the data and actions relevant to their role. Hospital data is isolated β no cross-hospital access.
Audit Logging
All significant actions (accreditation changes, booking approvals, session modifications, login events) are recorded in an immutable audit log for compliance and security monitoring.
Patient Information
TheatreLink is a theatre scheduling, coordination, and admissions platform. By default, booking records contain operational data only β procedure names, equipment requirements, scheduling details β and do not include identifiable patient information.
Hospitals may optionally enable the Admissions & Consent module, which collects patient demographics, medical history, and procedure consent on the hospitalβs behalf. When this module is in use, every patient record is protected by record-level AES-256-GCM envelope encryption: each record has its own Data Encryption Key, which is itself wrapped by a master key held in a managed Key Management Service. One-way HMAC-SHA256 hashes support patient matching without decryption.
Admissions and consent events are recorded in a hash-chained audit log anchored to an external RFC 3161 Time Stamp Authority so that any tampering is detectable. Patient-facing tokenised links are protected by a second factor (date of birth + postcode) and expire after a short window. The full data-handling description is in our Privacy Policy, and the platformβs data flows have been documented in an independent Privacy Impact Assessment that hospitals review as part of their information governance approval.
Infrastructure
- Hosting: Vercel (Sydney edge region) with automatic SSL/TLS certificate management
- Database: Neon PostgreSQL (AWS Sydney) with connection pooling and encrypted connections
- File Storage: Encrypted blob storage for accreditation documents
- Email: Resend β transactional email only, no marketing communications
- SMS: Twilio β session notification delivery only
- Real-Time: Pusher β encrypted WebSocket connections for live calendar updates
- Error Monitoring: Sentry β error tracking with PII scrubbing enabled
Security Headers
- HSTS: Strict-Transport-Security enforced with 2-year max-age and preload
- X-Frame-Options: DENY β prevents clickjacking attacks
- X-Content-Type-Options: nosniff β prevents MIME type sniffing
- Referrer-Policy: strict-origin-when-cross-origin
- Permissions-Policy: Camera, microphone, and geolocation access disabled
Compliance
- Australian Privacy Act 1988: Data stored exclusively in Australia, access controls enforced, no cross-border data transfers
- OWASP Top 10: Application security reviewed against OWASP guidelines including SQL injection prevention (Prisma ORM), XSS protection (React auto-escaping), CSRF protection (NextAuth tokens)
- HL7 FHIR Ready: Architecture prepared for future HL7 FHIR integration with healthcare systems
Responsible Disclosure
If you discover a security vulnerability in TheatreLink, please report it to security@theatrelink.com.au. We take all reports seriously and will respond within 48 hours.
theatrelink.com.au | support@theatrelink.com.au