Trust and security

healdesk is two systems. This website and the demo hold no patient information at all: a clinic owner's work email, a chat with a demo agent, a business enquiry. The product — the agent that answers your phone and chat — runs on separate infrastructure, under the Business Associate Agreement you sign at checkout, and that is the only place a caller's name, number or question ever lives.

The line is enforced in code, not policy: the marketing site's database schema is tested against a denylist of patient-shaped columns, and the product's database refuses to write patient information for any clinic until its agreement is bound and the clinic is deliberately moved to production.

• One clinic cannot see another. Every table that holds patient information carries row-level security that the application role cannot bypass and the table owner cannot skip. A test suite asserts, for every such table, that the policy exists, is forced, and names the clinic column.
• The AI says it is an AI, first. Every call, chat and DM opens with a line saying the patient is talking to an AI assistant; on the phone the same breath says the call is transcribed and that no audio recording is kept. The clinic cannot switch it off or edit it out through the greeting, and it is the first line of every transcript.
• Encryption. At rest in the database and object store, and in transit wherever we control both ends. Two routes are outside that: a phone call is not end-to-end encrypted, and a patient who telephones has chosen the telephone, which is the exception the Business Associate Agreement makes; and a message on Instagram, Messenger or WhatsApp travels through Meta's systems, which we do not control. Email that would carry patient information goes only over an encrypted connection, and is not sent if the receiving server cannot accept one.
• Where it runs. The product's servers and its database run in Amazon Web Services' US East region. The voice provider's region is being confirmed in writing, and appears on /subprocessors once it is.
• Every access is recorded. Reads and writes of patient information are written to an append-only audit table in the same transaction as the access, so an access that rolled back leaves no false claim behind, and a real one cannot be erased by the application.
• Logs cannot carry patient data. The product has a single logger with an allowlist of fields and a scrubber for numbers and addresses; a test fails the build on any log call that goes around it.
• No advertising platforms, anywhere. No pixel on this site, no conversion API in the product, and nothing about a patient is ever sent to Meta or Google for advertising; a browser policy on this site blocks the connections outright. Section 4 covers the two routes that carry patient details by design.
• Signed agreements are evidence. The exact text a clinic signed, its hash, who signed and when are stored append-only; the database role the application uses holds no permission to change or delete them.

3 vendors process patient information for the product. 1 has a countersigned Business Associate Agreement with us; 2 are pending. The full register, with what each receives and the status of each agreement, is at /subprocessors, and we tell every customer at least 15 days before a vendor is added. One more sits in the patient's path with no agreement possible, and is kept away from clinical content by design (section 4). 8 further vendors serve this website, the demo and billing and never receive patient information.

• Instagram, Messenger and WhatsApp. Meta signs no Business Associate Agreement for any messaging product, and no vendor in front of Meta can change that. So these channels are scoped to carry nothing clinical. A patient's message travels through Meta because that is where the patient wrote to you. Anything clinical in it is caught when it arrives, is not stored, is not repeated back and is not carried into a summary, and the assistant moves the conversation to a call or your own secure route and says why in one sentence. Replies never name a treatment.
• Deposits. A deposit is taken through your own payment processor account, under your own agreement with it, and Stripe, for one, signs no agreement on any tier. So a deposit link carries only an amount, a generic description and a reference code: no treatment name, not in the description, the statement descriptor or the metadata.
• The AI model keeps inputs for 30 days. Our model provider covers its API under its own Business Associate Agreement, but the models it covers require 30 days of data retention and cannot run with none. Even under that agreement it may keep content its automated trust-and-safety systems flag, or that the law requires it to keep, for up to two years. Everywhere else we push retention down; this one we cannot, so we say so here rather than leave it for your counsel to find.
• Your calendar is yours. Bookings are written into your own Google Calendar, under your own agreement with Google. That is the right place for them, and it is worth confirming your Google Workspace plan carries that agreement.
• Who we are. healdesk is a service of Viixi FZC, a company registered under the Sharjah Publishing City Free Zone, United Arab Emirates. HIPAA's obligations attach to a business associate wherever it is incorporated, and ours are in the agreement. Questions about data location, enforcement or our vendors go to the address in section 7.

We tell the clinic within five calendar days of discovering a breach of unsecured patient information — well inside the sixty days the rule allows, on purpose, so the clinic's own clock to notify its patients is not consumed by ours — and within five business days of any security incident, whether or not it turns out to be a breach. Who pays for what follows is in the agreement, not in small print: the cost of notifying patients and regulators sits with the clinic, and we carry no liability insurance. We say both plainly so a clinic can size its own cover.

• No certification. There is no "HIPAA certified" and we do not display a seal. HIPAA is a set of obligations, and the way to check ours is to read the agreement and ask us for the architecture.
• No third-party audit yet. No SOC 2 report exists. The controls above are our own and we will walk any reviewer through them.
• Two of the agreements above are not yet countersigned. Until every vendor in the patient-information path has signed, our operator moves no clinic to production. That is a check a person makes before switching a clinic over, not one the software enforces yet. The register says which agreements are outstanding.

Security questions, vulnerability reports and compliance questionnaires: privacy@healdesk.io. We answer within five business days and we do not pursue good-faith researchers.