---
title: 'EMR-AGENT: Automated EMR Preprocessing'
url: https://www.emergentmind.com/topics/emr-agent
type: topic
---

# EMR-AGENT: Automated EMR Preprocessing

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 [2510.00549]. 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 [2510.00549]. 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 [2510.00549].

## 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 [2510.00549]. 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 [2510.00549].

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 [2510.00549]. Within a single database, ambiguity in code mapping and cohort definitions can still arise from differing interpretations of instructions [2510.00549]. 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 [2510.00549].

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 [2401.07128], or interactive action-taking inside FHIR environments, such as MedAgentBench [2501.14654], 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) [2510.00549]. 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 [2510.00549].

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 [2510.00549]. 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 [2510.00549]. 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 [2510.00549]. 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 [2510.00549].

## 3. Cohort and feature selection workflow

Beyond Schema Linking and Guideline Generation, CFSA comprises three components: SQL-based Observation, SQL Generation, and Error Feedback [2510.00549]. 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 [2510.00549].

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

Once sufficient evidence has been gathered, CFSA generates the final SQL needed to extract the patient cohort, requested features, and required output format [2510.00549]. 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 [2510.00549]. The paper states that this loop repeats up to a maximum retry count [2510.00549].

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 [2510.00549]. It contains two principal modules: Feature Locating and Candidates Matching [2510.00549].

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

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 [2510.00549]. 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 [2510.00549]. The threshold controls the recall-precision tradeoff: lower thresholds increase recall, whereas higher thresholds increase precision [2510.00549].

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 [2510.00549]. 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 [2510.00549]. 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 [2510.00549].

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 [2510.00549]. 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 [2510.00549].

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 [2510.00549]. 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 [2510.00549]. Output constraints are strict: returning only SQL, avoiding code fences, preserving feature order, and using `CASE/WHEN` if necessary for code interpretation [2510.00549].

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 [2510.00549]. The benchmark uses three public ICU databases loaded into PostgreSQL: MIMIC-III v1.4, eICU v2.0, and SICdb v1.0.8 [2510.00549]. SICdb is manually converted to PostgreSQL, whereas the others use official scripts where possible [2510.00549].

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 language model’s knowledge cutoff [2510.00549]. 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 [2510.00549].

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 [2510.00549]. 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 [2510.00549]. Clinical experts build mapping dictionaries for each database, which serve as ground truth [2510.00549]. The number of distinct codes among these 56 features is reported as 126 for MIMIC-III, 53 for eICU, and 87 for SICdb [2510.00549].

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 [2510.00549]. CMA is evaluated with F1 and balanced accuracy, averaged over 3 runs [2510.00549]. Baselines are adapted versions of ICL(PLUQ), ICL(SeqSQL), DinSQL, and REACT, all given schema information and external documentation and adapted to PostgreSQL [2510.00549].

## 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 [2510.00549]. 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 [2510.00549]. The paper treats strong SICdb performance as evidence of generalization to an unseen schema [2510.00549].

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 [2510.00549]. For CMA, removing Candidates Matching collapses performance to near zero on most datasets, and removing the Schema Guideline also reduces performance [2510.00549]. 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 [2510.00549].

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 [2510.00549]. Claude-family models are described as strongest or near-strongest in this setting [2510.00549].

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 [2510.00549]. 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 [2510.00549]. Code mapping performance remains materially below perfect, indicating that this subproblem is not solved [2510.00549].

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 [2401.07128], MedAgentBench evaluates action-taking in FHIR-style EMR environments [2501.14654], and Medi-Gemma separates deterministic EMR analytics from generative reasoning with explicit ground-truth injection [2607.04907]. 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.

Source: https://www.emergentmind.com/topics/emr-agent