Real-World Evidence Data Characteristics
Real-World Evidence (RWE) data for clinical trial pre-screening comes primarily from Electronic Health Records (EHR), medical claims databases, patient registries, wearable device data, and patient-reported outcomes (PROs). This data is often a mix of unstructured and semi-structured formats, including free-text clinical notes, diagnostic codes (e.g., ICD-10), medication records (e.g., ATC classification), laboratory results, and imaging reports. Data update frequencies vary; EHRs may update in real-time, while claims data typically processes quarterly or annually in batches. Document lengths differ significantly, ranging from hundreds of characters for a single outpatient visit to tens of thousands for an inpatient medical record. Fields contain numerous medical terms, abbreviations, and units such as dosage (mg/kg), frequency (QD/BID), and time (days/weeks/months), with low standardization.
Constraints from These Characteristics on Multi-Turn Conversations and Prompts
The highly unstructured nature of RWE data demands stronger semantic understanding in multi-turn conversations to extract key patient characteristics from free text. Inconsistent data updates require the system to handle information with varying time granularities and to explicitly state data recency in prompt design. Long documents and medical terminology pose challenges for traditional segmentation and retrieval methods, necessitating optimized segmentation strategies to maintain contextual integrity and enhanced medical vocabulary recognition and standardization. Low field standardization means prompts must be fault-tolerant and capable of inference to accurately match patient inclusion/exclusion criteria, for example, understanding different expressions for disease diagnoses. In multi-turn conversations, users may progressively refine screening conditions, requiring the system to dynamically adjust retrieval scope and results.
Configuration Guidelines
| Configuration Item | Recommended Value | Rationale for Recommendation |
|---|---|---|
Chunk size | 500–800 characters | Balances contextual integrity of medical text with retrieval efficiency, avoiding overly long segments that cause redundancy or overly short ones that lose critical information. |
Recall count | 8–12 entries | Ensures coverage of enough relevant patient record fragments to address the dispersed nature of RWE data. |
Similarity threshold | Calibrate by measurement | Determine through experimentation based on the specific RWE dataset and complexity of pre-screening conditions to effectively distinguish relevant from irrelevant results. |
Rerank result count | 3–5 entries | Selects the most relevant fragments from the recalled results, reducing the processing burden on the LLM and focusing on core information. |
maxContext | 4096 tokens | Accommodates the characteristics of long documents in RWE data, ensuring multi-turn conversations can carry sufficient historical information and retrieved document fragments. |
promptTemplate | Include instructions like "Please extract the patient's disease diagnosis, medication history, laboratory indicators" | Guides the model to extract key clinical information required for pre-screening from unstructured text, addressing the issue of insufficient data standardization. |
Common Pitfalls
- During a conversation, the message "No eligible patients found" may appear. This can happen if knowledge base segmentation granularity is inappropriate, leading to critical information being split or context lost, preventing the model from effective retrieval.
- The system may misunderstand numerical fields like patient age or weight in multi-turn conversations, displaying "field is empty" or an incorrect value. This typically occurs because the prompt does not clearly specify units or numerical ranges, or because RWE data contains multiple expressions that have not been uniformly processed.
- After a user modifies screening conditions, the system may still provide results based on old conditions, with a status code of 422. This might be due to incomplete state management in multi-turn conversations, failing to update or clear historical session context in a timely manner.
Verification of Configuration
- For a set of simulated queries containing typical inclusion/exclusion criteria, check whether the model can accurately identify the target patient group after multi-turn conversations and provide corresponding reasons.
- Run retrieval on patient medical record data of varying lengths. Verify if the returned knowledge base fragments completely contain the medical entities and values involved in the query. Check the recall performance of the
Similarity thresholdfor different queries. - Conduct multi-turn conversation tests. Gradually add, modify, or delete pre-screening conditions. Observe whether the system correctly updates its internal state and consistently performs retrieval and responds based on the latest conditions.
Note: The values provided are common starting points. Measure them 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.