Multi-turn Conversation and Prompts for Home Medical Device

Data Characteristics for This Category

Pharmacovigilance data for home medical devices (e.g., blood glucose meters, blood pressure monitors, nebulizers) primarily originates from voluntary user reports, manufacturer after-sales feedback, and medical institution monitoring. Data update frequencies vary. User reports can be real-time, while manufacturer feedback is typically aggregated in batches or cycles. Document formats are diverse, including unstructured user feedback text, structured adverse event report forms (e.g., FDA MedWatch or EMA EudraVigilance), and semi-structured device log files. Common fields include patient demographics (age, gender), device model, usage time, drug name, adverse event description, event date, and management actions. Units involve time (years, months, days, hours), dosage (milligrams, units), and measurement (mmHg, mmol/L).

Constraints Imposed by These Characteristics on "Multi-turn Conversation and Prompts"

The multi-source and unstructured nature of home medical data requires multi-turn dialogue systems to have robust text understanding and information extraction capabilities. Colloquial descriptions mixed with professional terminology in voluntary user reports necessitate more refined semantic analysis from the dialogue system to accurately identify adverse event symptoms and related medications. Uncertain update frequencies mean the knowledge base must support dynamic updates and version management, ensuring the dialogue system always relies on the latest vigilance information. The structured nature of form data allows for more constraints and guidance in prompt design, such as using slot filling to standardize user input. Time-series data and specific error codes in device log files demand prompt parsing logic that can translate these technical details into understandable natural language.

Configuration Settings

Configuration Item	Recommended Value	Rationale
`maxContext`	8–12 turns	Simulates common doctor-patient communication turns, ensuring contextual coherence and avoiding redundant information interference.
`temperature`	0.3–0.5	Reduces the randomness of model-generated content, ensuring professionalism and accuracy, and minimizing hallucinations.
`top_p`	0.8–0.9	Prioritizes higher probability words while maintaining some diversity, improving output reliability.
`recallNum`	10–15 items	Increases the number of relevant adverse event reports retrieved from the knowledge base, improving information coverage.
`similarityThreshold`	0.75–0.85	Ensures retrieved knowledge segments are highly relevant to the user's query, filtering out inaccurate or irrelevant information.
`promptTemplate`	Calibrate based on actual measurements	For home medical scenarios, includes placeholders to guide users in providing key information such as device model and medication history.

Three Common Mistakes

The model frequently re-asks for information already provided in the conversation, leading to a poor user experience. This occurs when maxContext is set too low, or the context management logic fails to effectively identify and utilize key entities from historical conversations.
The model misinterprets user descriptions of adverse events, providing irrelevant suggestions. This happens when similarityThreshold is set too high or the knowledge base lacks sufficient diverse cases, leading to overly narrow knowledge retrieval.
The model fails to correctly identify and associate device error codes reported by users with specific risks. This is due to the prompt template lacking instructions for parsing device logs or error codes, or the knowledge base not establishing a mapping between error codes and adverse events.

How to Verify Configuration

Simulate multi-turn conversations. Observe if the model can accurately identify and utilize user-provided device models, drug names, and adverse event descriptions across different turns to assess the effectiveness of context management.
Prepare a series of user report cases containing colloquial descriptions and professional terminology. Test the model's recall accuracy and relevance at different similarityThreshold values, ensuring retrieved knowledge matches the cases.
Input scenarios containing specific device error codes. Verify if the model can correctly parse the error codes and associate them with potential risks or solutions, checking the prompt's ability to process structured information.

The values provided are common starting points. Measure against your own samples.

Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-09-21.