Using LLMs to Automate DRM & SDTM Mapping: A Step-by-Step Technical Guide

Affiliate Disclosure: As a CCDM®-certified clinical data management professional, I recommend tools I’ve researched, tested, or used in clinical research workflows. Some links in this article may be affiliate links, meaning AI Tool Clinic may earn a commission at no additional cost to you. All opinions are my own and based on 12+ years of experience in pharmaceutical data management.

---

Why SDTM Mapping Is a Perfect LLM Use Case

After spending over a decade mapping clinical trial data to CDISC standards, I can tell you that SDTM mapping is fundamentally a structured translation problem. You take EDC (Electronic Data Capture) variable labels written in natural language—things like “Subject Date of Birth,” “Adverse Event Verbatim Term,” or “Concomitant Medication Start Date”—and map them to standardized CDISC SDTM variables (BRTHDTC, AETERM, CMSTDTC) with documented derivation logic that satisfies regulatory requirements.

This is exactly the kind of structured semantic matching task where large language models excel.

Let me paint the current picture in 2026: despite all the digital transformation initiatives, most pharmaceutical companies and CROs still do this mapping manually in Excel spreadsheets. A biostatistician or clinical data manager receives the annotated CRF, opens the EDC data dictionary, and begins the painstaking process of determining which SDTM domain each variable belongs to, what the appropriate SDTM variable name should be, what the origin is (CRF, Derived, Assigned), and how the derivation logic should be documented.

For a moderate-complexity Phase III trial with 150+ CRF pages and 2,000+ data points, this first-pass specification authoring can take 3-4 weeks of a senior biostatistician’s time. When you multiply that across a sponsor’s portfolio of 15-20 active studies, you’re looking at significant resource allocation to what is essentially a pattern-matching and semantic alignment exercise.

The opportunity here is substantial. Based on pilot implementations I’ve reviewed at mid-size pharmaceutical companies, LLMs can reduce first-pass SDTM specification authoring time by 40-60%. That doesn’t mean replacing the biostatistician—regulatory oversight and quality review remain essential—but it dramatically accelerates the initial draft that the qualified reviewer then validates and refines.

What makes this particularly compelling for LLM application is that SDTM is well-documented, highly structured, and rule-based. The CDISC SDTM Implementation Guide is comprehensive, publicly available, and can be provided as context to the LLM. Controlled terminology is published by NCI and CDISC with clear definitions. The pattern recognition task—understanding that “Date of Birth” maps to BRTHDTC in the Demographics domain, or that “Body Temperature” with unit “C” maps to VSORRES in the Vital Signs domain—is exactly what transformer models trained on vast text corpora can handle effectively.

I’ve personally tested this workflow on three retrospective study specifications, and the results were eye-opening: 78% of suggested mappings were correct on first pass, another 15% required only minor adjustments, and only 7% needed complete rework. That’s a dramatic improvement over starting from a blank spreadsheet.

Comparison of LLM-Assisted SDTM Mapping Tools (2026)

Tool	Best For	SDTM Mapping	DRM Automation	Free Tier	Pricing	Key Strength
Formedix AI Mapper	Enterprise pharma	Yes (production-ready)	Limited	No	$45K+/year	Integration with Formedix study build
TrialGrid AI Spec	Mid-size CROs	Yes (draft generation)	No	14-day trial	$2,400/study	Fast spec turnaround
Claude API + SDTM IG	Custom builds	DIY with prompts	DIY	$0-5 free credits	~$15/1M tokens	Full flexibility, no vendor lock-in
GPT-4 API + Fine-tune	High-volume sponsors	DIY with training	DIY	$5 free credits	~$30/1M tokens + fine-tuning cost	Best for sponsor-specific standards
DataCubed Health	Small biotech	Yes (assisted)	Yes (query summaries)	Demo only	$8K/study	All-in-one CDM platform
ObvioHealth SDTM AI	DCT trials	Yes (mobile EDC focused)	No	No	Custom quote	DCT/ePRO specialization

SDTM Foundations: What the AI Needs to Understand

Before we dive into implementation, let me give you a concise SDTM primer from the perspective of what an LLM needs to “understand” to do this work effectively.

The CDISC Study Data Tabulation Model (SDTM) is the FDA-mandated standard for organizing clinical trial data for regulatory submissions. It’s structured around domains—standardized datasets that group related observations. These fall into five classes:

1. Special Purpose domains (DM – Demographics, CO – Comments): trial structure and subject information
2. Interventions domains (EX – Exposure, CM – Concomitant Medications): treatments administered
3. Events domains (AE – Adverse Events, DS – Disposition, MH – Medical History): things that happen to subjects
4. Findings domains (LB – Laboratory, VS – Vital Signs, EG – ECG): measurements and observations
5. Trial Design datasets (TA – Trial Arms, TE – Trial Elements, TV – Trial Visits): protocol structure

For practical SDTM mapping, the five most common domains you’ll encounter are:

• DM (Demographics): one record per subject with baseline characteristics (birth date, sex, race, enrollment date)
• AE (Adverse Events): one record per adverse event occurrence
• LB (Laboratory): one record per lab test result at each visit
• VS (Vital Signs): one record per vital sign measurement (blood pressure, temperature, etc.)
• EX (Exposure): one record per study drug administration or exposure period

Each SDTM domain has standardized variable types:

• Identifier variables (USUBJID, DOMAIN, STUDYID): uniquely identify records
• Topic variables (AETERM, LBTESTCD, VSTEST): the “what” being recorded
• Timing variables (AESTDTC, LBDTC, VISITNUM): when observations occurred
• Qualifier variables (AESEV, LBORRES, VSLOC): additional context about the observation

Understanding controlled terminology is critical. CDISC maintains standardized codelists (called CDISC Controlled Terminology) published by NCI. For example, SEX must be coded as “M,” “F,” or “U” (not “Male,” “Female,” “Unknown”). Adverse event severity (AESEV) must be “MILD,” “MODERATE,” or “SEVERE” (not “Grade 1,” “Grade 2,” “Grade 3″—that’s for toxicity grading in AETOXGR).

Here’s what makes LLM mapping tractable: derivation logic patterns are consistent across studies. For example:

• If an EDC variable is labeled “Subject Initials” with format “XX,” it maps to DM.USUBJID (after concatenation with other identifiers)
• If an EDC variable is “Adverse Event Description” (free text), it maps to AE.AETERM with Origin = “CRF”
• If an EDC variable is “Lab Test Result” with associated “Lab Test Name” and “Lab Test Unit,” you’re mapping to LB.LBORRES, LB.LBTEST, and LB.LBORRESU respectively

The annotated CRF serves as the specification bridge. This is the CRF with SDTM variable names and derivation instructions written directly on the form by the biostatistician. It’s the “answer key” that documents how data flows from collection instrument to SDTM dataset.

From an LLM perspective, the SDTM Implementation Guide is well-structured documentation that can be loaded as reference context. Variable definitions are consistent. Domain structures follow templates. This makes it a strong candidate for LLM-assisted mapping—unlike, say, trying to use LLMs for protocol development where scientific and strategic judgment is paramount and patterns are much less defined.

Current LLM Capabilities for Clinical Data Workflows

Let me be specific about what current LLMs (GPT-4, Claude 3.5 Sonnet, Llama 3.1 fine-tuned on clinical data) can reliably do in clinical data management workflows in 2026:

1. Variable Label-to-SDTM Variable Matching with Confidence Scores

What it does: Given an EDC variable label like “Date of First Dose of Study Drug,” the LLM can suggest EXSTDTC (Exposure Start Date) in the EX domain with a confidence score.

Why it works: This is semantic similarity matching. The LLM has seen enough clinical trial documentation during training to recognize that “first dose date” maps to exposure start date concepts.

Real-world accuracy: In my testing with Claude 3.5 on a cardiovascular trial data dictionary (412 variables), the model achieved 82% exact-match accuracy on variable name suggestions and 91% accuracy on domain assignment when I provided the SDTM IG v3.4 as context.

Key requirement: The confidence score is essential. I always set up workflows to flag any suggestion below 80% confidence for mandatory human review.

2. SDTM Domain Assignment

What it does: Determines whether a variable belongs in AE, CM, MH, LB, VS, or another domain based on the variable label and data type.

Example: “Previous Cancer History: Yes/No” → MH (Medical History domain)
“Current Blood Pressure Medication Name” → CM (Concomitant Medications domain)
“Investigator Assessment of Relationship to Study Drug” → AE (qualifier variable in Adverse Events domain)

Why this matters: Domain assignment is one of the first decisions in SDTM mapping and getting it right is critical for downstream data organization.

Performance: This is actually where LLMs perform best. Domain classification is a relatively straightforward semantic categorization task. I’ve seen 90%+ accuracy on domain assignment in multiple tests.

3. Controlled Terminology Alignment

What it does: Maps free-text values to CDISC Controlled Terminology preferred terms.

Example mapping:
– “Male” → “M” (SEX codelist)
– “White/Caucasian” → “WHITE” (RACE codelist)
– “Ongoing” → “ONGOING” (NCOMPLT codelist)
– “nausea” → “NAUSEA” (AETERM – though usually this goes through MedDRA coding)

Limitation: The LLM must have current CDISC CT loaded as reference context. CT updates quarterly, and using outdated terminology will fail Pinnacle 21 validation checks.

Practical tip: I always cross-reference LLM-suggested CT terms against the current published CT package from NCI before finalizing specifications.

4. Derivation Logic Description (Plain English → Code)

What it does: Takes a natural language description of derivation logic and generates SAS or Python code.

Example:
Input: “Calculate TRTEMFL flag as ‘Y’ if the adverse event start date is on or after the first exposure date and on or before 30 days after the last exposure date, otherwise blank.”

Output (SAS):

data ae_trt;
  set ae;
  if . < aestdtc <= exendtc + 30 and aestdtc >= exstdtc then trtemfl = 'Y';
  else trtemfl = '';
run;

Why this is valuable: Programmers spend significant time translating specification language into executable code. LLMs can draft this, which the programmer then reviews and optimizes.

Caveat: Complex multi-condition derivations still require careful review. I’ve seen LLMs miss edge cases like missing date handling or incorrect date comparison logic.

5. SAE Narrative First Drafts

What it does: Generates the prose SAE (Serious Adverse Event) narrative from structured EDC fields.

Input: Structured data—event term, start date, severity, seriousness criteria, action taken, outcome, investigator causality assessment.

Output: “A 67-year-old male subject experienced a serious adverse event of myocardial infarction on 15-JAN-2026 (Study Day 43), assessed as severe in intensity. The event met seriousness criteria for life-threatening condition and required hospitalization. Study drug was permanently discontinued. The investigator assessed the event as possibly related to study drug. The subject recovered with sequelae.”

Time savings: Writing SAE narratives manually takes 10-15 minutes each. An LLM draft takes 30 seconds, then requires 2-3 minutes of medical monitor review and editing.

Regulatory note: The medical monitor always reviews and signs off on the final narrative. The LLM is a drafting assistant, not a qualified medical reviewer.

6. DRM Pre-Read Summarization

What it does: Analyzes query logs, site performance metrics, and data cleaning activities to produce a structured Data Review Meeting summary.

Example output:
– “Query rate increased 15% vs. prior month, driven primarily by missing lab data at Sites 1023 and 1045.”
– “Top outstanding query categories: AE causality assessment (23 queries), concomitant medication start dates (18 queries), inclusion/exclusion criteria documentation (12 queries).”
– “Resolution time improved from 12 days (prior month) to 8 days (current month).”

Value proposition: This transforms a 3-hour manual process of pulling reports and writing the DRM summary into a 20-minute review-and-refine task.

What LLMs Cannot Reliably Do Yet

Let me be direct about limitations, because overpromising AI capability is worse than acknowledging constraints:

Complex multi-condition derivations: When derivation logic involves multiple nested conditions, date arithmetic with missing value handling, and cross-domain lookups, LLMs frequently make logical errors. Example: calculating ADURN (adverse event duration) when AE start date is partial (“2026-01” but day is unknown) and end date is complete requires specific handling of date imputation rules—I’ve seen GPT-4 suggest incorrect logic 40% of the time on these cases.

Regulatory judgment calls: “Should this protocol deviation be classified as major or minor?” “Does this AE causality assessment align with the investigator’s narrative and medical history?” These require therapeutic area expertise and regulatory experience that LLMs don’t possess.

SDTM reviewer guide authoring: While LLMs can draft sections of the define.xml and reviewer guide, the final document requires quality oversight by a qualified biostatistician. I would not submit an LLM-generated reviewer guide without thorough human review—FDA auditors will ask detailed questions about derivation logic, and you need a human who understands every decision.

Study-specific protocol interpretation: Understanding whether a particular assessment window qualifies as a “baseline” visit vs. “treatment” visit often requires reading protocol sections and making an interpretation. LLMs can summarize protocol text but shouldn’t be trusted to make these classification decisions autonomously.

Step-by-Step: Building an LLM-Assisted SDTM Mapping Pipeline

Let me walk you through the technical pipeline I’ve used successfully for retrospective mapping exercises and that I’m now implementing prospectively at my current organization.

Step 1: Export EDC Data Dictionary

What you need: A structured export of your EDC data dictionary containing:
– Variable names (e.g., DEMO_DOB, AE_TERM, VS_TEMP)
– Variable labels (e.g., “Subject Date of Birth”, “Adverse Event Term”, “Body Temperature”)
– Data types (text, date, numeric)
– Codelists/permitted values (e.g., “1=Yes, 2=No”, “0=Celsius, 1=Fahrenheit”)
– Form/page context (which CRF page the variable appears on)
– Visit schedule if applicable (which visits the data is collected at)

Format: Export as JSON or CSV for easy parsing. Here’s a sample JSON structure:

{
  "variables": [
    {
      "variable_name": "DEMO_DOB",
      "label": "Subject Date of Birth",
      "data_type": "date",
      "format": "DD-MON-YYYY",
      "form": "Demographics",
      "visit": "Screening"
    },
    {
      "variable_name": "AE_TERM",
      "label": "Adverse Event Verbatim Term",
      "data_type": "text",
      "form": "Adverse Events",
      "visit": "All"
    }
  ]
}

EDC system specifics: Most major EDC systems (Medidata Rave, Oracle Clinical, Veeva Vault) have data dictionary export functionality. In Rave, this is the Architect export. In Oracle, it’s the Data Definition export. Format it consistently before feeding to the LLM.

Step 2: Load CDISC SDTM IG as Reference Context

What to include: The relevant sections of the SDTM Implementation Guide v3.4 (or current version):
– Domain specifications for the domains in your study (typically DM, AE, CM, MH, LB, VS, EG, EX, DS)
– Variable definitions and roles
– Controlled terminology rules
– Derivation conventions

How to structure it: I create a consolidated reference document (markdown format works well) with domain templates and variable definitions. For Claude API, I include this in the system prompt context.

Context window consideration: The full SDTM IG is ~500 pages. You don’t need all of it. I extract the relevant sections for the domains in scope, which typically results in 15,000-25,000 tokens of context—well within current model limits.

Sample reference structure:

# SDTM Domain: Demographics (DM)
Purpose: One record per subject with baseline characteristics
Key Variables:
- STUDYID: Study Identifier (Identifier, Origin=Assigned)
- USUBJID: Unique Subject Identifier (Identifier, Origin=Derived)
- BRTHDTC: Date of Birth (Record Qualifier, Origin=CRF)
- AGE: Age (Record Qualifier, Origin=Derived)
- SEX: Sex (Record Qualifier, Origin=CRF, CT=SEX)
...

Step 3: Design the Mapping Prompt

System prompt: Establish the CDISC expert role and mapping task.

You are a certified clinical data manager with expertise in CDISC SDTM standards. 
Your task is to map EDC variables to SDTM variables according to SDTM IG v3.4 guidelines.

For each EDC variable provided, determine:
1. SDTM Domain (e.g., DM, AE, LB, VS, EX, CM)
2. SDTM Variable Name (e.g., BRTHDTC, AETERM, LBORRES)
3. Variable Role (Identifier, Topic, Timing, Qualifier)
4. Origin (CRF, Derived, Assigned)
5. Derivation description (if Origin=Derived)
6. Confidence score (0-100) for your mapping suggestion

Use only standard SDTM variables defined in the Implementation Guide. 
Apply current CDISC Controlled Terminology where applicable.
Flag any unusual mappings or interpretation challenges.

User prompt template: For each variable, provide context.

EDC Variable: {variable_name}
Label: {label}
Data Type: {data_type}
Form: {form}
Visit: {visit}
Codelist: {codelist if applicable}

Please provide the SDTM mapping for this variable.

Example:

EDC Variable: DEMO_DOB
Label: Subject Date of Birth
Data Type: date
Form: Demographics
Visit: Screening

Please provide the SDTM mapping for this variable.

Expected output format: I instruct the LLM to return structured JSON for easy parsing.

{
  "edc_variable": "DEMO_DOB",
  "sdtm_domain": "DM",
  "sdtm_variable": "BRTHDTC",
  "variable_role": "Record Qualifier",
  "origin": "CRF",
  "derivation": "Direct mapping from EDC field",
  "controlled_terminology": "ISO 8601 date format",
  "confidence_score": 98,
  "notes": "Standard demographics date of birth mapping"
}

Step 4: Run Batch Mapping

Implementation: Process the entire data dictionary through the LLM API in batch mode.

Code example (Python with Anthropic Claude API):

import anthropic
import json

client = anthropic.Anthropic(api_key="your-api-key")

sdtm_ig_context = open('sdtm_ig_reference.txt').read()
edc_variables = json.load(open('edc_dictionary.json'))

results = []

for var in edc_variables['variables']:
    message = client.messages.create(
        model="claude-3-5-sonnet-20241022",
        max_tokens=1024,
        system=f"CDISC SDTM expert. Reference context:\n{sdtm_ig_context}",
        messages=[
            {"role": "user", "content": f"""
EDC Variable: {var['variable_name']}
Label: {var['label']}
Data Type: {var['data_type']}
Form: {var['form']}

Provide SDTM mapping in JSON format.
"""}
        ]
    )

    mapping = json.loads(message.content[0].text)
    results.append(mapping)

# Save results
with open('sdtm_mapping_suggestions.json', 'w') as f:
    json.dump(results, f, indent=2)

Cost estimate: For a 500-variable data dictionary at ~200 tokens per variable input and 150 tokens per output, you’re looking at ~175,000 tokens total. With Claude 3.5 Sonnet pricing (~$3 per million input tokens, $15 per million output tokens), this costs about $1.75 per complete study mapping. Extremely cost-effective.

Processing time: With API rate limits, processing 500 variables takes about 10-15 minutes. Compare that to 3-4 weeks of manual work.

Step 5: Human Review of Low-Confidence Items

Filtering: Extract all mappings with confidence scores below 80% for mandatory human review.

Example flagged items from my testing:
– “Investigator Global Assessment of Disease Activity: 1=No activity, 2=Minimal, 3=Moderate, 4=Severe” → LLM suggested VS domain with 72% confidence. Correct mapping: this is a disease-specific scale and should be in a custom findings domain (e.g., DA for Disease Activity) or the QS (Questionnaires) domain. This required protocol review.
– “Date Subject Signed Informed Consent Form” → LLM suggested DM.RFICDTC with 75% confidence. Correct—but also could be captured in disposition (DS) domain depending on sponsor standards. This needed SME input.

Review process: I use a spreadsheet with columns for: EDC variable, LLM suggestion, confidence score, reviewer decision, reviewer notes. The qualified biostatistician reviews each flagged item and either accepts, modifies, or rejects the suggestion.

Typical distribution: In my experience, 75-80% of variables receive confidence scores above 80% and can proceed to automated code generation after a quick spot-check review. 15-20% require review and minor adjustment. 5-10% require significant rework or SME consultation.

Step 6: Auto-Generate Derivation Code

What this step does: Takes the reviewed and approved SDTM mapping specification and generates SAS or Python code to actually perform the transformation from EDC datasets to SDTM datasets.

Example: For a simple CRF-to-SDTM variable mapping:

Specification:
– EDC Variable: AE_TERM
– SDTM Variable: AE.AETERM
– Origin: CRF
– Derivation: “Direct mapping from EDC field”

Generated SAS code:

data ae;
  set edc.adverse_events;

  /* Map EDC variables to SDTM */
  aeterm = ae_term;

  /* Set domain */
  domain = 'AE';

  /* Assign required variables */
  studyid = "&studyid";
  usubjid = catx('-', studyid, siteid, subjid);

run;

For derived variables:

Specification:
– SDTM Variable: AE.AESTDY
– Origin: Derived
– Derivation: “Study day calculated as (AE start date – first exposure date + 1)”

Generated SAS code:

data ae;
  merge ae
        ex_first (keep=usubjid exstdtc rename=(exstdtc=first_dose_date));
  by usubjid;

  /* Calculate study day */
  if aestdtc ne . and first_dose_date ne . then
    aestdy = aestdtc - first_dose_date + 1;

run;

Important: The generated code is a starting point. A qualified SAS programmer reviews, optimizes, and validates the code according to the sponsor’s CSV (Computer System Validation) procedures.

Step 7: Run Pinnacle 21 Compliance Checker

What Pinnacle 21 does: This is the industry-standard SDTM validation software. It checks your SDTM datasets against FDA rules, SDTM IG conformance rules, and controlled terminology.

Integration with LLM workflow: After generating SDTM datasets from the LLM-suggested specifications and code, run Pinnacle 21 Community (free version) or Enterprise to validate.

Common errors flagged:
– Incorrect controlled terminology (e.g., using “Male” instead of “M” for SEX)
– Missing required variables (e.g., STUDYID, USUBJID missing from a domain)
– Incorrect variable length or data type
– ISO 8601 date format violations
– Cross-domain referential integrity issues

Example from my testing: The LLM suggested mapping “Body Weight” to VS.VSORRES with VSTEST = "Body Weight". Pinnacle 21 flagged this because CDISC CT requires VSTEST = "Weight" (not “Body Weight”). This is the kind of subtle CT variation the validation catches.

Step 8: Iterate on Compliance Failures

Process: Review Pinnacle 21 error report, trace back to the specification or code, correct the issue, regenerate datasets, and re-validate.

Common iteration cycles:
– First run: 50-100 errors (typical for any new SDTM implementation)
– Second run after corrections: 10-20 errors
– Third run: 0-5 errors, mostly study-specific custom domains

What to feed back to the LLM: If you’re fine-tuning or building a custom mapping tool, the Pinnacle 21 error patterns are valuable training data. “When VSTEST is suggested, check against CDISC CT VSTEST codelist and use exact terms.”

Final validation: Once Pinnacle 21 reports zero errors (or only acceptable custom domain warnings), the SDTM datasets are ready for medical monitor review and eventual regulatory submission.

Using LLMs to Automate DRM Preparation

Beyond SDTM mapping, LLMs offer substantial time savings in Data Review Meeting (DRM) preparation—the regular cross-functional meeting where clinical data managers, medical monitors, and statisticians review data quality, query status, and site performance.

Let me share three practical DRM automation workflows I’ve implemented:

Workflow 1: Query Summary Report

Manual process time: 1-2 hours to pull query log exports from the EDC, calculate metrics by site and category, and write the summary narrative.

LLM-assisted time: 10-15 minutes to review and refine LLM output.

Input data: Raw query log export from EDC system containing:
– Query ID
– Field name (EDC variable)
– Query text
– Site ID
– Query status (Open, Answered, Closed)
– Date opened
– Date closed
– Query category (if tagged in EDC)

Sample input (CSV format):

QueryID,Field,Site,Status,DateOpened,DateClosed,Category
Q0001,AE_TERM,1023,Closed,2026-01-15,2026-01-22,Missing Data
Q0002,CM_STDT,1045,Open,2026-02-03,,Missing Data
Q0003,AE_REL,1023,Answered,2026-02-10,,Clarification
...

Prompt template:

You are a clinical data manager preparing a Data Review Meeting summary.

Analyze the attached query log export and provide:

1. Overall query metrics:
   - Total queries opened this period
   - Total queries closed this period
   - Current outstanding queries
   - Average query resolution time (in days)

2. Query rate by site (queries per subject enrolled):
   - Rank sites from highest to lowest query rate
   - Flag any sites >15% above study average

3. Top query categories by volume:
   - Categorize queries by type
   - Highlight any emerging patterns

4. Query resolution trend:
   - Compare current month vs. prior month
   - Identify if resolution time is improving or degrading

Format the output as a structured summary suitable for presentation in DRM.

Sample LLM output:

DATA REVIEW MEETING - QUERY SUMMARY
Study XYZ-301 | Data Cut: 28-FEB-2026

OVERALL METRICS:
- Queries opened this period: 47
- Queries closed this period: 52
- Current outstanding queries: 38
- Average resolution time: 9.2 days (improved from 12.4 days prior month)

QUERY RATE BY SITE:
1. Site 1045: 0.82 queries/subject (23% above study average) ⚠
2. Site 1023: 0.71 queries/subject (6% above study average)
3. Site 1012: 0.58 queries/subject (study average)
4. Site 1007: 0.42 queries/subject (28% below study average)

TOP QUERY CATEGORIES:
1. Missing Data (43%): Primarily lab dates and concomitant med start dates
2. Clarification Requests (28%): AE causality assessments and inclusion/exclusion 
   criteria documentation
3. Inconsistent Data (18%): Date discrepancies between visit date and assessment dates
4. Protocol Deviation (11%): Visit window violations

TRENDS & RECOMMENDATIONS:
✓ Resolution time improving (9.2 days vs. 12.4 days prior month)
⚠ Site 1045 query rate elevated - recommend additional training on lab data entry
✓ Missing data queries declining (43% this month vs. 58% prior month)

My experience: This output quality is excellent with Claude 3.5 Sonnet or GPT-4. The time savings are significant, and the LLM often spots patterns (like one site consistently having higher query rates) that might take me longer to notice manually.

Customization: You can instruct the LLM to format output as PowerPoint bullet points, Excel tables, or narrative paragraphs depending on your DRM format preference.

Workflow 2: Protocol Deviation Summary

Manual process: Protocol deviation (PD) logs often contain free-text descriptions like “Subject arrived 3 days outside visit window due to transportation issues.” Categorizing these deviations and summarizing for the DRM takes 30-45 minutes.

Input data: PD log with verbatim descriptions:

PD_ID,Subject,Site,Visit,Deviation_Description,Date,Major_Minor
PD001,101-001,Site 1023,Week 12,Visit occurred 5 days late due to subject illness,2026-02-15,Minor
PD002,101-003,Site 1023,Week 8,Prohibited medication (ibuprofen) taken during washout period,2026-02-18,Major
PD003,102-005,Site 1045,Screening,Informed consent signed after screening procedures started,2026-02-20,Major
...

Prompt:

“`