Data Characteristics
Pharmacovigilance data for rational drug use primarily originates from national drug adverse reaction monitoring centers, healthcare institution reporting systems, and spontaneous monitoring data from some pharmaceutical companies. This data updates frequently, typically in monthly or quarterly batches. Some urgent adverse event reports may be pushed in real-time. The document structure mainly consists of structured tabular data. Fields include basic patient information, drug information (brand name, generic name, batch number, manufacturer), adverse reaction event descriptions (symptoms, onset time, outcome), and event severity assessment. The data often involves medical terminology, dosage units (e.g., mg, g, ml), frequency units (e.g., times/day, week), and disease codes (e.g., ICD-10). Some unstructured data appears as handwritten doctor's notes or patient self-reports.
Deployment and Upgrade Constraints from Data Characteristics
High-frequency data updates require efficient data ingestion and incremental update capabilities to avoid full re-indexing. The coexistence of structured and unstructured data demands more from the knowledge base's preprocessing module. This requires loading specialized dictionaries and handling synonyms for medical terminology to ensure accurate query recall. The presence of dosage and frequency units means unit standardization or unit conversion functionality is necessary during knowledge base construction for model understanding and inference. Specialized fields like ICD-10 codes require validation during the data cleaning phase and may need mapping to more general disease descriptions. Deployment requires reserving sufficient storage and computing resources to handle data growth and complex query demands, while ensuring data privacy and security compliance. During upgrades, data schema changes can invalidate existing indexes, necessitating smooth data migration and version compatibility mechanisms.
Configuration Settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
UPLOAD_FILE_MAX_SIZE | 500 MB | Handles uploading CSV or Excel files containing large amounts of structured data |
PARSE_FILE_TIMEOUT_SECONDS | 600 seconds | Processes large adverse reaction report files, ensuring parsing completion |
Segment Length | 800–1200 characters | Balances context for long adverse event descriptions with vector embedding efficiency |
Recall Count | Top 10 | Ensures coverage of multi-faceted relevant information, improving answer comprehensiveness |
Similarity Threshold | Calibrated by actual measurement, 0.75-0.85 range recommended | Balances recall rate and accuracy, reducing interference from irrelevant information |
maxContext | 10000 characters | Accommodates more adverse reaction case details, supporting complex inference |
Common Pitfalls
- A "validation failed" message when configuring the message receiving address on the DingTalk Open Platform usually indicates the deployment environment does not expose a public IP or a firewall is blocking access from DingTalk servers.
- After local deployment, even without an internet connection for version updates, the lack of pre-loaded medical terminology dictionaries leads to misunderstandings of specialized terms in adverse reaction event descriptions, affecting answer accuracy.
- Knowledge base query results fail to effectively identify drug dosage and frequency units, returning recommended dosages inconsistent with actual medication situations. This occurs because unit standardization was not performed during data preprocessing or the model was not trained to understand unit information.
Verification Steps
- Upload a structured data file containing typical adverse reaction cases. Check if the knowledge base correctly parses fields and generates searchable content.
- Enter queries containing medical terminology and dosage units. Verify that the system's answers are accurate and correctly understand and process unit information, for example,
dexamethasone 5mg/day. - Simulate high-concurrency queries. Monitor system response time and resource utilization to confirm the deployment environment can handle the expected load.
- In an offline environment, attempt to use the deployed knowledge base for question answering. Verify that all necessary data and models are localized and do not require external connections.
The values provided are common starting points and should be measured against the reader's 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.