No. SleekAI is configured to refuse all medical advice, treatment recommendations, and individualized clinical statements. Emergency symptoms route the user to 911 or their local emergency number immediately. The boundary is enforced in the system prompt and reinforced by the guideline filter, and it holds even when the user describes specific symptoms in detail. The bot can explain what the product does for clinicians and patients in aggregate, but never substitutes for a clinician-patient interaction. That posture is the only safe one for any chatbot on a healthtech site, vendor or provider.

Yes, if you publish it on the Compliance page. The bot reads from your real Compliance entries, including HIPAA BAA availability by plan, HITRUST CSF certification level (i1 or r2), SOC 2 Type II status, and any clinical-validation studies. It does not invent regulatory claims, because false compliance statements create both regulatory and patient-safety exposure. The system prompt explicitly forbids claiming certifications that are not on the page, and the conversation log captures any place where a buyer's expectation does not match published reality.

Yes. The bot reads your integrations directory, so Epic App Orchard validation status, Cerner Code app status, SMART on FHIR resource coverage, OAuth scopes, and any FHIR profile constraints all become queryable. CIOs evaluating a pilot need this level of specificity to confirm integration feasibility before pilot scoping, and the bot can quote your real posture in one sentence with a citation to the integration doc. Vague integration claims are the most common cause of failed healthtech pilots; the bot enforces specificity by quoting from real published content.

The bot refuses to engage with individualized care questions and routes the user to their own clinician. The system prompt explicitly forbids any clinical assessment, treatment suggestion, or medication-related statement. For emergency keywords (chest pain, suicidal ideation, severe bleeding, breathing difficulty), the bot surfaces 911 or local emergency services and the suicide-and-crisis lifeline (988 in the US) immediately. Patient-facing surfaces should also be excluded from the chatbot via display conditions when the system prompt cannot be designed for patient self-service safely.

Yes. SleekAI is multibot, so a clinician-facing portal can run a clinical-workflow bot, a patient-facing site can run a patient-information bot, and the marketing site runs the buyer-facing bot. Each gets its own system prompt with different refusal boundaries: a clinician-workflow bot can quote dosing references that are already part of your published clinical content, where a patient-facing bot would refuse the same question. Display conditions scope each bot to the right URL pattern, so the boundaries cannot be circumvented by URL guessing.

Yours. SleekAI is BYO API key, so you bring your own OpenAI, Anthropic, Google, or OpenRouter key. For healthtech specifically, BYO posture matters because security review will require knowing exactly which model provider sees the conversations, under what BAA, and with what retention posture. The provider you choose must sign a HIPAA BAA before any PHI flows through it, which the major model providers offer for enterprise accounts. The marketing-site bot generally avoids PHI by design (display conditions exclude patient-facing pages), which keeps the chatbot surface out of PHI scope entirely.

On your WordPress install. You control retention and exports, and you can pipe interesting conversations to a Slack channel for the GTM team via webhook. For healthtech sites the fact that conversations never touch a third-party SaaS, except the LLM API you chose, is often the deciding factor over hosted chat tools in security and privacy review. Logs include model name, token usage, and the page URL, which makes attribution and audit straightforward. Retention can be set to a short window (24 hours or 7 days) to match data-minimization expectations.

The conversation logs are stored in your WordPress database with timestamp, model, and page URL, so producing a sample is a database export. The bot's refusal patterns are deterministic at the system-prompt level, so demonstrating to a regulator that no medical advice was offered on a sampled date range is straightforward: the system prompt is auditable, the guideline filter is auditable, and the log itself is searchable. That auditability is one of the reasons mature healthtech teams prefer chatbot infrastructure they own over hosted alternatives where the data and the policy both live in a third-party SaaS.