EMR-AGENT: Automated EMR Preprocessing

• EMR-AGENT is an agent-based framework that replaces hard-coded SQL rules with dynamic, schema-aware reasoning to automate EMR preprocessing.
• It adopts a dual-agent architecture (CFSA and CMA) to iteratively refine cohort selection, feature extraction, and code mapping using SQL as both a retrieval and observational tool.
• The framework achieves high F1 scores across diverse databases and generalizes to unseen schemas, emphasizing the critical role of live database interaction and error feedback.

Searching arXiv for EMR-AGENT and closely related EMR-agent literature to ground the article. EMR-AGENT is an agent-based framework for automating cohort selection, feature extraction, and code mapping from Electronic Medical Record (EMR) databases by replacing hard-coded, database-specific preprocessing rules with dynamic large-language-model interaction over schema, documentation, and live SQL access (Lee et al., 1 Oct 2025). It is designed for the clinical machine-learning preprocessing stage, where structured variables must be extracted from heterogeneous databases before downstream modeling, and it treats SQL not only as a retrieval language but also as an instrument for database observation and decision making (Lee et al., 1 Oct 2025). In the paper introducing the framework, EMR-AGENT is evaluated through the PreCISE-EMR benchmark over MIMIC-III, eICU, and SICdb, including an unseen-schema setting, to test whether an agent can generalize across institution-specific database structures without hand-crafted logic (Lee et al., 1 Oct 2025).

1. Problem setting and motivation

Clinical prediction pipelines depend on structured data extracted from EMRs, yet the extraction process is commonly implemented through manual, database-specific preprocessing for cohort definition, feature selection, and code mapping (Lee et al., 1 Oct 2025). The paper identifies these pipelines as hard-coded and brittle, tied to specific schemas, expensive to port across institutions, and a source of irreproducibility and poor cross-dataset generalization (Lee et al., 1 Oct 2025).

Two forms of heterogeneity are central. Across databases and institutions, the same clinical concept may appear as an item identifier, a column, or a row value, depending on schema design (Lee et al., 1 Oct 2025). Within a single database, ambiguity in code mapping and cohort definitions can still arise from differing interpretations of instructions (Lee et al., 1 Oct 2025). EMR-AGENT addresses this by replacing expert-authored preprocessing rules with agents that inspect schemas, reason over manuals and evaluation memos, query the database interactively, and generate SQL dynamically (Lee et al., 1 Oct 2025).

This framing places EMR-AGENT in a distinct part of the medical-agent landscape. Unlike systems focused on question answering over EHRs through executable code generation, such as EHRAgent (Shi et al., 2024), or interactive action-taking inside FHIR environments, such as MedAgentBench (Jiang et al., 24 Jan 2025), EMR-AGENT is concerned with upstream data standardization and extraction from heterogeneous clinical databases. A plausible implication is that it targets the infrastructure bottleneck preceding model development rather than bedside interaction.

2. Architectural organization

EMR-AGENT is organized as a two-agent framework consisting of the Cohort and Feature Selection Agent (CFSA) and the Code Mapping Agent (CMA) (Lee et al., 1 Oct 2025). Both agents follow a shared high-level pattern: Schema Linking and Guideline Generation, task-specific reasoning and exploration, SQL-based database interaction, and iterative refinement using observations and error feedback (Lee et al., 1 Oct 2025).

The agents consume three input types: a natural-language user request, documents including the database manual and evaluation memo, and schema information including tables, columns, and sample values per column (Lee et al., 1 Oct 2025). From these sources, the framework constructs a Schema Guideline that explains what linked tables and columns mean, how they should be used, what remains missing or ambiguous, and what SQL should do next (Lee et al., 1 Oct 2025). This mechanism is more than conventional schema linking: it produces an operational specification for subsequent database interaction.

The division of labor is explicit. CFSA handles cohort selection and feature extraction, whereas CMA resolves database-specific coding for requested clinical features (Lee et al., 1 Oct 2025). The framework’s defining architectural claim is that SQL is not merely the final output; it is used as an intermediate observational tool for examining unknown categorical values, hidden mappings, sample content, and other schema properties needed to decide what to extract (Lee et al., 1 Oct 2025).

3. Cohort and feature selection workflow

Beyond Schema Linking and Guideline Generation, CFSA comprises three components: SQL-based Observation, SQL Generation, and Error Feedback (Lee et al., 1 Oct 2025). The workflow begins by determining whether the current schema understanding is sufficient to form the requested query. If not, the agent generates observation SQL to inspect the database, for example by retrieving distinct values when categorical encodings are unknown (Lee et al., 1 Oct 2025).

The SQL-based Observation process has three steps. First, SQL Sufficiency Assessment decides whether existing information is enough and, if not, emits exploratory SQL (Lee et al., 1 Oct 2025). Second, Data Sufficiency Check inspects returned results to determine whether they reveal useful information; if the result is uninformative, observation repeats (Lee et al., 1 Oct 2025). Third, Schema Update incorporates newly observed facts into the evolving schema interpretation and guideline (Lee et al., 1 Oct 2025).

Once sufficient evidence has been gathered, CFSA generates the final SQL needed to extract the patient cohort, requested features, and required output format (Lee et al., 1 Oct 2025). Error Feedback then classifies failures into three categories: Syntactic Error, which triggers immediate regeneration; Schema Mismatch, where the SQL is syntactically valid but semantically wrong, empty, or malformed and therefore causes the agent to return to schema linking with the error as feedback; and Correct Result, which finalizes output (Lee et al., 1 Oct 2025). The paper states that this loop repeats up to a maximum retry count (Lee et al., 1 Oct 2025).

This design makes database interaction epistemic as well as operational. The agent does not assume that the schema is self-explanatory; it probes the database until it has enough evidence to write extraction SQL. That is the mechanism by which the framework avoids reliance on schema-specific hand coding.

4. Code mapping workflow

CMA begins with the same schema-guideline stage, but its task is to map a user-requested feature to the correct codes or schema definitions in the database (Lee et al., 1 Oct 2025). It contains two principal modules: Feature Locating and Candidates Matching (Lee et al., 1 Oct 2025).

Feature Locating first checks whether the exact feature name appears literally in a column name. If so, the corresponding schema element is returned (Lee et al., 1 Oct 2025). Otherwise, the agent assumes the feature may be encoded as a row value or may not exist directly as a column (Lee et al., 1 Oct 2025). This distinction is important in databases such as eICU, where features can appear either as columns or as coded row values (Lee et al., 1 Oct 2025).

Candidates Matching has two stages. Candidates Listing uses SQL DISTINCT queries to enumerate candidate combinations from tables and columns that may contain feature code, name, or unit (Lee et al., 1 Oct 2025). Target and Candidates Matching then compares the requested feature with candidate strings in batches, assigns similarity scores from 0 to 100, and retains only candidates above a user-specified threshold (Lee et al., 1 Oct 2025). The threshold controls the recall-precision tradeoff: lower thresholds increase recall, whereas higher thresholds increase precision (Lee et al., 1 Oct 2025).

The paper emphasizes that this is not simple string matching. CMA uses schema-aware reasoning, documentation, and live enumeration of code-like values to recover database-specific definitions for standardized features (Lee et al., 1 Oct 2025). In this respect, EMR-AGENT addresses a long-standing clinical informatics problem: clinically equivalent measurements are encoded inconsistently across institutions and even within the same institution.

5. SQL as retrieval and observation

A central conceptual contribution of EMR-AGENT is its dual use of SQL. On one level, SQL performs retrieval: extracting patient cohorts, feature values, and code mappings (Lee et al., 1 Oct 2025). On another, SQL is used for observation and decision making: inspecting distinct categorical values, sample records, hidden mappings, potential table-column locations for concepts, and whether a result is sufficient to proceed (Lee et al., 1 Oct 2025).

This distinction separates EMR-AGENT from conventional text-to-SQL formulations. In the framework, SQL output is often intermediate evidence rather than the final answer (Lee et al., 1 Oct 2025). The paper argues that EMR preprocessing requires iterative observation, reasoning over heterogeneous schemas, and verification against returned rows, rather than a one-shot translation from natural language to SQL (Lee et al., 1 Oct 2025).

The prompting logic reflects this. CFSA prompts instruct the model to identify relevant schema for cohort and requested features, produce a schema guideline, indicate missing information, use SQL to retrieve unknown categorical values, update schema guidance after observations, and generate the final query only when sufficient evidence exists (Lee et al., 1 Oct 2025). CMA prompts similarly require identifying only definition schema, excluding measurement-value columns, extracting code, name, and unit metadata, using DISTINCT, and matching candidates by similarity threshold (Lee et al., 1 Oct 2025). Output constraints are strict: returning only SQL, avoiding code fences, preserving feature order, and using CASE/WHEN if necessary for code interpretation (Lee et al., 1 Oct 2025).

This suggests that EMR-AGENT can be read as an agentic reformulation of database preprocessing: instead of “translate request to query,” the operative question is “what must be learned from the database before a valid query can be written?”

6. Benchmarking with PreCISE-EMR

To evaluate the framework, the paper introduces PreCISE-EMR, a standardized benchmark for EMR preprocessing with two task tracks: Cohort and Feature Selection, and Code Mapping (Lee et al., 1 Oct 2025). The benchmark uses three public ICU databases loaded into PostgreSQL: MIMIC-III v1.4, eICU v2.0, and SICdb v1.0.8 (Lee et al., 1 Oct 2025). SICdb is manually converted to PostgreSQL, whereas the others use official scripts where possible (Lee et al., 1 Oct 2025).

The benchmark explicitly distinguishes seen and unseen schema settings. MIMIC-III and eICU are treated as familiar benchmark-style settings, whereas SICdb is treated as unseen because it was released after the LLM’s knowledge cutoff (Lee et al., 1 Oct 2025). The databases also differ structurally: MIMIC-III has 26 tables, SICdb has 7 tables, and eICU has 31 tables with a more complex structure in which features can appear as both columns and row values (Lee et al., 1 Oct 2025).

For cohort and feature selection, the ground truth is constructed by varying common exclusion criteria such as age, gender, missing discharge information, minimum ICU duration, exclusion of multiple ICU stays, missing gender, and minimum number of clinical records (Lee et al., 1 Oct 2025). For code mapping, the benchmark defines 56 standardized features limited to vital signs and laboratory results, based on standardized terminology from Athena/OHDSI and reference feature definitions from HiRID (Lee et al., 1 Oct 2025). Clinical experts build mapping dictionaries for each database, which serve as ground truth (Lee et al., 1 Oct 2025). The number of distinct codes among these 56 features is reported as 126 for MIMIC-III, 53 for eICU, and 87 for SICdb (Lee et al., 1 Oct 2025).

Evaluation uses F1 as the main metric for CFSA, together with accuracy for required output formats of gender, age, mortality, and length of stay, each averaged over 10 runs (Lee et al., 1 Oct 2025). CMA is evaluated with F1 and balanced accuracy, averaged over 3 runs (Lee et al., 1 Oct 2025). Baselines are adapted versions of ICL(PLUQ), ICL(SeqSQL), DinSQL, and REACT, all given schema information and external documentation and adapted to PostgreSQL (Lee et al., 1 Oct 2025).

7. Reported results, ablations, and limitations

On cohort and feature selection, EMR-AGENT substantially outperforms the reported baselines across all three databases, with F1 and accuracy of 0.94 and 0.893 on MIMIC-III, 0.929 and 0.951 on eICU, and 0.814 and 0.794 on SICdb (Lee et al., 1 Oct 2025). On code mapping, the framework reports F1 and balanced accuracy of 0.516 and 0.283 on MIMIC-III, 0.648 and 0.336 on eICU, and 0.536 and 0.38 on SICdb (Lee et al., 1 Oct 2025). The paper treats strong SICdb performance as evidence of generalization to an unseen schema (Lee et al., 1 Oct 2025).

Ablation studies identify live database interaction as the most critical component for CFSA: removing SQL-based Observation reduces performance, removing Error Feedback causes a major drop, removing both database interaction modules causes a large collapse, and removing the Schema Guideline also hurts (Lee et al., 1 Oct 2025). For CMA, removing Candidates Matching collapses performance to near zero on most datasets, and removing the Schema Guideline also reduces performance (Lee et al., 1 Oct 2025). The paper additionally reports that manuals and evaluation memos matter: removing documents reduces performance across both tasks, especially for CMA, and increases observation SQL usage as the agent compensates by probing the database more often (Lee et al., 1 Oct 2025).

Backbone sensitivity is substantial. On SICdb, reported CFSA F1 ranges from 0.22 for Qwen2.5-72B to 0.81 for Claude-3.5-Sonnet, while CMA F1 ranges from 0.14 for Llama-3.1-70B to 0.63 for Claude-3.7-Sonnet (Lee et al., 1 Oct 2025). Claude-family models are described as strongest or near-strongest in this setting (Lee et al., 1 Oct 2025).

The limitations are explicit. The paper states that EMR-AGENT is not a replacement for human experts, may not match the precision of hand-built dataset-specific pipelines, and still requires expert validation of extracted data (Lee et al., 1 Oct 2025). It assumes access to database manuals, evaluation memos, schema metadata, and live SQL access, and it can still struggle when documentation is incomplete, categorical values are not discoverable via observation, mapping thresholds are mis-set, or the database structure is highly unusual (Lee et al., 1 Oct 2025). Code mapping performance remains materially below perfect, indicating that this subproblem is not solved (Lee et al., 1 Oct 2025).

In the broader research context, EMR-AGENT exemplifies a shift from static NLP over medical records toward agentic, tool-mediated reasoning over clinical data systems. Related work explores complementary parts of this space: EHRAgent reframes EHR reasoning as code synthesis and execution (Shi et al., 2024), MedAgentBench evaluates action-taking in FHIR-style EMR environments (Jiang et al., 24 Jan 2025), and Medi-Gemma separates deterministic EMR analytics from generative reasoning with explicit ground-truth injection (Quadri et al., 6 Jul 2026). Taken together, these works suggest that “EMR agents” are converging on a common systems principle: clinically reliable behavior depends on deterministic access to structured state, explicit tool use, and iterative verification rather than unconstrained language generation alone.