--- name: Den nära experten — Digital Behavior type: governance status: anchor depends_on: [1-den-nara-experten-karnguid.md, foundation/voice] propagates_to: [aleris-design-governance.md] open_questions: [OQ-06] last_verified: 2026-03-21 --- # Den nära experten — digital behavior **What Aleris digital products do and don't do** Version 1.0 — 2026 (draft) Audience: product teams, designers, developers *Part 4 of 4. Assumes familiarity with [1] Core guide. Companion document: [3] Digital voice and micro-copy.* --- ## What this document covers — and what it doesn't This document describes *behavior* — what Aleris digital products do, what boundaries they hold, and how they act in different situations. It doesn't cover how the text sounds (that's the voice document's responsibility) but what the system *should and shouldn't do*. The boundary: the voice document determines how a sentence is phrased. This document determines whether the sentence should be written at all. --- ## Medical boundary Aleris digital products — including AI chats — inform, navigate, and refer. They don't diagnose, recommend treatment, or interpret individual clinical results. **The product can:** Explain processes, timelines, and logistics. Describe what happens in a phase. Summarize general information about a procedure or examination. **The product cannot:** Answer symptom questions, assess whether a condition requires care, give individual medical recommendations, or interpret test results. **When the right answer is "contact a person"** — that's the answer the product gives. Without hedging, with a specific referral. --- ## Phase awareness Digital products that follow a patient journey should know where the patient is in the process and adapt behavior accordingly. - **Before:** The product helps with preparation, explanation, and logistics. It answers questions about what will happen. - **During:** The product provides real-time support if needed — but doesn't initiate contact unprompted. - **After:** The product helps with recovery, follow-up, and contact. It answers questions about what's normal and when to seek care. Phase awareness means the system *doesn't* give preparation instructions to a patient who has already had surgery, and *doesn't* present post-care instructions before the patient knows what the procedure involves. --- ## Referral logic When a question falls outside the product's capability, the referral must be specific — not generic. **A specific referral contains:** Who the patient should contact (name or function) + how (phone number, email, or channel). **Generic referrals to avoid:** "Contact your healthcare provider", "Talk to your doctor", "Reach out to customer service" — without specifying who, where, or how. If the product doesn't know who to refer to, that's a configuration gap — not a design question. --- ## AI chat guardrails ### What the chat never does - Gives medical advice — symptom interpretation, diagnostic suggestions, treatment recommendations - Fabricates information — if the answer isn't available, the chat says so - Discourages the patient from seeking care - Guesses — uncertainty is handled by acknowledging the boundary and referring ### What the chat always does - Responds within its knowledge domain (process, logistics, preparation, general information) - Acknowledges uncertainty directly and refers onward with specifics - Respects which phase the patient is in ### Medical disclaimer Shown once in the chat UI — not repeated in every response. The disclaimer is a UI element, not part of the chat voice. --- ## Consent and data information Consent information is presented clearly and separately — never embedded in flow text, instructions, or patient guides. - Consent is collected actively (opt-in), not through passive acceptance - Each consent statement specifies what it covers and where to find more information - The information is written in plain language — but this document doesn't govern the *phrasing* (the voice document does) --- ## State and status handling ### Progression locks The patient cannot skip phases or tasks that must be completed in order. This protects against mistakes — it's an act of care, not a restriction. ### Status messages Events driven by staff (assessment approved, surgery scheduled, insurance decision) appear to the patient as status banners — not as tasks the patient can check off. The patient should see what happened, but not confirm things only staff can verify. ### Feedback without interruption Confirmations and error messages are shown inline, not in modals. Modals interrupt flow and create anxiety ("Did I do something wrong?"). Inline feedback provides the same information without taking control away from the user. --- ## What's not covered here This document describes product behavior at a level that applies regardless of specific product. Product-specific behavior decisions — which phases exist in a given patient journey, which documents are required, which referral contacts apply — belong in each product's own documentation. Clinical threshold decisions (when is a value abnormal, which findings require urgent contact) are medical judgments, not product design. They are made by clinicians and configured, not designed. --- ## Status This document is a draft. It collects behavior principles that have so far lived embedded in product-specific design documents (Aleris Patient Product Design Guidelines, ALERIS-DESIGN-WORKING.md) and lifts them to a level that applies across all digital products. Priority areas to develop: 1. Referral logic — template for how products are configured with correct contact paths 2. Phase awareness — generalized model beyond individual patient journeys 3. AI behavior on unexpected results (Mode C in the design working document) — how the product acts when a patient shifts from calm to anxious --- *Digital behavior complements [3] Digital voice and micro-copy. Based on Aleris Patient Product Design Guidelines and ALERIS-DESIGN-WORKING.md.*