Designing LLM Dialogue Systems for Health Consultation: Problem Definition and Capability Boundaries
Health-related questions require more than general-purpose search or chat responses because they are professional, directly affect user decisions, and often arise outside clinic hours. This article explains why health information dialogue needs dedicated design, defines the appropriate role of an LLM-based system, and presents a three-tier capability boundary model for direct answers, cautious answers, and refusal with transfer to human or emergency services. It also discusses why boundary rules should be implemented as verifiable configuration and code rather than relying only on prompts.
1. Problem Definition: Why Health Information Dialogue Needs Dedicated Design
Users often have health-related questions in daily life, such as “What does an elevated indicator in this medical report mean?”, “Can these two medications be taken at the same time?”, or “At what temperature does a child with a fever need medical attention?” These questions share three common characteristics: they are highly professional, the answers directly affect user decisions, and the questions often arise outside clinic hours.
General search and ordinary chat tools can cover some of these needs, but they expose several clear problems in health scenarios. First, result sources are mixed, making it difficult for users to judge whether information comes from an authoritative organization. Second, the tone of an answer may be too certain, treating general advice as a personal diagnosis. Third, recognition of emergency symptoms is insufficient, and the system may give a bland response when the user most needs clear guidance.
Therefore, the goal of a health dialogue system should be explicitly limited to helping users understand medical information, organize their own situation, judge which type of institution they should visit, and promptly transfer to human services or emergency channels when risk increases. The system does not replace a doctor in making a diagnosis, nor does it replace a pharmacist in reviewing medication. This positioning determines every subsequent design choice.
2. Capability Boundaries: Clearly Define What Can Be Answered, What Requires Caution, and What Must Be Transferred
Boundary design is the first engineering task for a health dialogue system. User questions should be divided into three levels.
| Level | Typical Questions | System Behavior |
|---|---|---|
| Directly answerable | Explanations of medical terms, general health education, general advice on diet and daily routines, basic knowledge of disease prevention | Generate answers based on a vetted knowledge base, with sources and a disclaimer |
| Answer with caution | Interpretation of examination report indicators, basic medication knowledge, advice related to individual circumstances | Provide a general explanation, clearly state that a doctor’s or pharmacist’s opinion is required, and do not provide personalized dosages |
| Refuse and transfer | Emergency signs, tendency toward self-harm or harm to others, requests to prescribe or adjust prescriptions, requests for a definitive diagnosis | Stop routine generation, output a fixed safety message, and direct the user to emergency or human services |
Boundary rules should be written as verifiable configurations rather than relying only on prompts. Prompts can guide the tone and structure of answers, but interception actions must be executed by the rule layer and the code layer.
