Security, privacy and hospital network access
This page exists so a doctor can forward one link to their hospital’s IT or information-security team. It states plainly what Dr.Club is, what data it handles, what it will never handle, and exactly what needs to be allowed through a web filter.
What Dr.Club is
Dr.Club is a browser-based marketing tool that helps doctors and other healthcare professionals plan, write and publish social media posts about their own practice and specialty. It is operated by DrClub LLC, a Delaware limited liability company, and served from Dover, DE, United States.
It is explicitly not a medical device, an electronic health record, a telehealth platform or a clinical decision-support tool. It is closer in category to a design or marketing application than to anything clinical, and it should be reviewed as business software.
What data Dr.Club handles
- Account identity: your name, email address and profile photo if you set one.
- Professional profile: your medical specialty, practice focus, target audience and content goals.
- Content you generate: post text, images and schedules created inside Dr.Club.
- Social media access tokens for accounts you choose to connect, encrypted at rest and deleted immediately when you disconnect.
- Usage and billing records. Card details are handled by Stripe and never reach Dr.Club's servers.
What Dr.Club never handles
- Protected Health Information (PHI) of any kind.
- Patient names, identifiers, medical record numbers, conditions, diagnoses, prescriptions or notes.
- Diagnostic images or any clinical data.
- Anything drawn from a hospital system. Dr.Club has no integration with, and no access to, any clinical system.
Dr.Club’s database contains no patient records and no PHI fields. Entering patient information is prohibited by our Terms of Use, and because no PHI is ever received, Dr.Club is not a HIPAA business associate and does not sign Business Associate Agreements.
Domains to allow through your web filter
Dr.Club is a general business/software application, not a social network. If your filter has categorised it under “Social Networking” or left it uncategorised, we would ask that it be classified as Business & Economy or Software / Technology.
| Domain | Purpose |
|---|---|
| www.drclub.com | The application itself. HTTPS (TCP 443) only. |
| drclub.com | Redirects to www.drclub.com. HTTPS (TCP 443) only. |
| mtxwxrrvxrzlpxdodesn.supabase.co | Supabase: authentication, application database and image storage. Required for sign-in. HTTPS (TCP 443) only. |
| checkout.stripe.com / billing.stripe.com | Stripe: subscription checkout and billing portal. Only needed when a user starts or manages a subscription. |
| accounts.google.com / www.linkedin.com | Only if a user chooses single sign-on with Google or LinkedIn instead of an email code. Email sign-in needs neither. |
| lh3.googleusercontent.com / media.licdn.com | The user's own profile photo, only if they sign in with Google or LinkedIn. Blocking these hides the photo and nothing else. |
| www.clarity.ms | Microsoft Clarity: optional product analytics, loaded only after a user accepts cookies. Blocking it has no effect on the application. |
Only the first three rows are needed for a doctor to sign in and create content. Connecting a social media account additionally requires the user’s browser to reach that network’s own sign-in page; if your policy blocks social networks, Dr.Club still works fully in copy-and-paste mode.
What Dr.Club does not need
- No WebSocket connections. Dr.Club uses ordinary HTTPS request/response traffic only, so TLS-inspecting proxies that block wss:// will not break it.
- No non-standard ports. Everything runs on TCP 443.
- No browser plugin, desktop agent, installer or local service.
- No access to hospital systems, EHR/EMR, PACS, directories or shared drives.
- No inbound connections to the hospital network.
Security posture
- All traffic is served over HTTPS with TLS 1.3 and HTTP Strict Transport Security.
- Modern security response headers are set on every response:
Strict-Transport-Security,X-Content-Type-Options: nosniff,X-Frame-Options: DENY,Referrer-Policy, a restrictivePermissions-Policyand a Content Security Policy. - Data is encrypted in transit and at rest; access is controlled per user by row-level security.
- Authentication is passwordless: a one-time code sent to a verified email address, or single sign-on with Google or LinkedIn. No passwords are stored.
- Payment card data is handled entirely by Stripe and never touches Dr.Club’s systems.
- Social media access tokens are encrypted at rest and deleted the moment an account is disconnected.
- A machine-readable security contact is published at
/.well-known/security.txtper RFC 9116.
Sub-processors
Hosting and content delivery (Vercel), database, authentication and file storage (Supabase), AI text and image generation (Google), payments (Stripe), transactional email (Resend) and optional, consent-gated product analytics (Microsoft Clarity). The complete list, with retention periods and international-transfer safeguards, is in our Privacy Policy.
Contact for security questions
Security and vulnerability reports: support@drclub.com. Privacy and data-subject requests: privacy@drclub.com. We aim to respond to security enquiries from healthcare IT teams within two business days.