EMR-AGENT: Automating Cohort and Feature Extraction from EMR Databases

Anonymous Author(s)^*,

Institution Name
ICLR 2026

Cohort/Feature Selection Agent (CFSA) Example

Cohort Selection: Include only male ICU patients between the age 70 and 89 who have only single admission in their lifetime.
Features: ICU-stay id, gender(Male/Female/Unknown), age(integer), mortality status(Dead/Alive/Unknown).

1.Schema Linking and Guideline Generation: Feature Schema

Get all schema information about user-defined clinical requests.

2.SQL-based Observation : SQL Sufficiency Assessment

Use LLM to judge whether the selected Schema information is sufficient to make SQL to extract user-requested [Cohort Selection] and [Features].
In this case, LLM think the selected Schema information is enough to make SQL. So, we pass other path in "SQL-based Observation".

3.SQL Generation

Make SQL with information we got from STEP 1.

4.Error Feedback

Execute SQL to obtain [Cohort Selection] and [Features]. But we get SQL Error.
So, we do Error Feedback to define problems about error. LLM think, its error is caused by wrong schema selection.
Then, we go back to step 1 [Schema Linking and Schema Guideline]. If we didn't get Error in this step, we could end CFSA.

1.Schema Linking and Guideline Generation (Retry)

Retry [Schema Linking and Scehma Guideline], with [Error Feedback] information from step 4.

2.SQL-based Observation : SQL Sufficiency Assessment (Retry)

Use LLM again to judge whether the selected Schema information is sufficient to make SQL to extract user-requested [Cohort Selection] and [Features].
In this example, LLM think we need more information to make correct SQL.
Thus, LLMs generates observation SQLs to gain additional information.

2.SQL-based Observation : Data Sufficiency Check

Execute observation SQLs to obtain extra information from Database.
Then, LLM decides whether the observed information already exists in the [Selected Schema] and [Schema Guideline] or it offers additional important information.

2.SQL-based Observation : Update Schema Linking and Schema Guideline

Update the [Selected Scehma] and [Schema Guideline] with the additional information obtained from the previous step.

2.SQL-based Observation : SQL Sufficiency Assessment (After observation)

Use LLM to judge whether the updated Schema information ([Selected Schema] and [Schema Guideline]) is sufficient to make SQL to extract user-requested [Cohort Selection] and [Features].
With additional information, LLM think Schema information is now enough to generate SQL.

3.SQL Generation (Retry)

With updated Schema information ([Selected Schema] and [Schema Guideline]), LLM generates final SQL again.

5.Excute SQL & Test

We then execute the generated SQL to obtain user-requested [Cohort Selection] with [Features] as a tabular format.
With the obtained table data, we compare our result with True csv file with our evaluation metrics.

Code Mapping Agent (CMA) Example

[Target Feature]: Mapping code of Hematocrit [Volume Fraction] of Blood (Lab-Test) for SICDB database.

1.Schema Linking and Guideline Generation : Mapping Schema

Get definition schema information for the user-requested feature ("Hematocrit [Volume Fraction] of Blood (Lab-Test)").
It is important to find schema information that can tell which table or column is related to the user-requested feature.

1.Schema Linking and Guideline Generation : Feature Schema

Get all schema information related to the user-requested feature.

2.Feature Locating

Use LLM to check whether the user-requested feature exists in column location from the [Selected Schema].
In this case, LLM decides that user-requested feature does not exist in the column location.

3.Candidates Matching - Candidates Listing

LLM generates two SQL to list candidates from two tables since LLM from previous step selected two tables to search for the user-requested feature.

3.Candidates Matching - Target and Candidates Matching

Compare each candidate to the user-requested feature and list only the candidates that has higher similarity score than the user-defined similarity threshold score.

3.Candidates Matching - Target and Candidates Matching

After the initial comparsion process, we merge the remaining candidates into one list and compare them with the user-requested feature once again.

4.Final Code mapping Results

Merge matching result(s) which has higher similarity score(s) than user-defined similarity score threshold.
Finally, we obtain the user-requested mapping code(s) for the target EMR database ("Hematocrit [Volume Fraction] of Blood (Lab-Test)" in SICdb).

📌 Application of EMR-AGENT

Our EMR-AGENT framework, CFSA and CMA, can be applied to automatically generate Event Stream Dataset for downstream clinical tasks such as mortality prediction without any hard-coded rules.
Here, we present an example application where CMA generates an SQL query conditioned on time constraints, which is then integrated with CFSA’s SQL query to produce the final Event Stream Dataset.

Integration Example

I want only male ICU patients between the age 70 and 89 who have only single admission in their lifetime
and who measure Heart rate within 48 hours after ICU admission.
I am looking for age, gender as static features and mortality status for prediction,
and Heart rate(Vital Sign) information about name, values, unit, measurement time in MIMIC-III database.

Use Code mapping Agent & Cohort Agent

Use each Agent for its role. Then get each schema information & guideline, feature matching results, and cohort SQL.

SQL generation

Use an LLM to generate an integrated SQL query that satisfies user requested conditions, including the event stream dataset and target time range.

Make final integration csv file

Excute integration SQL to target database. Then make user requested csv file.

EMR-AGENT: Automating Cohort and Feature Extraction from EMR Databases

Abstract

Cohort/Feature Selection Agent (CFSA) Example

1.Schema Linking and Guideline Generation: Feature Schema

Get all schema information about user-defined clinical requests.

2.SQL-based Observation : SQL Sufficiency Assessment

Use LLM to judge whether the selected Schema information is sufficient to make SQL to extract user-requested [Cohort Selection] and [Features]. In this case, LLM think the selected Schema information is enough to make SQL. So, we pass other path in "SQL-based Observation".

3.SQL Generation

Make SQL with information we got from STEP 1.

4.Error Feedback

1.Schema Linking and Guideline Generation (Retry)

Retry [Schema Linking and Scehma Guideline], with [Error Feedback] information from step 4.

2.SQL-based Observation : SQL Sufficiency Assessment (Retry)

Use LLM again to judge whether the selected Schema information is sufficient to make SQL to extract user-requested [Cohort Selection] and [Features]. In this example, LLM think we need more information to make correct SQL. Thus, LLMs generates observation SQLs to gain additional information.

2.SQL-based Observation : Data Sufficiency Check

Execute observation SQLs to obtain extra information from Database. Then, LLM decides whether the observed information already exists in the [Selected Schema] and [Schema Guideline] or it offers additional important information.

2.SQL-based Observation : Update Schema Linking and Schema Guideline

Update the [Selected Scehma] and [Schema Guideline] with the additional information obtained from the previous step.

2.SQL-based Observation : SQL Sufficiency Assessment (After observation)

Use LLM to judge whether the updated Schema information ([Selected Schema] and [Schema Guideline]) is sufficient to make SQL to extract user-requested [Cohort Selection] and [Features]. With additional information, LLM think Schema information is now enough to generate SQL.

3.SQL Generation (Retry)

With updated Schema information ([Selected Schema] and [Schema Guideline]), LLM generates final SQL again.

5.Excute SQL & Test

We then execute the generated SQL to obtain user-requested [Cohort Selection] with [Features] as a tabular format. With the obtained table data, we compare our result with True csv file with our evaluation metrics.

Code Mapping Agent (CMA) Example

1.Schema Linking and Guideline Generation : Mapping Schema

Get definition schema information for the user-requested feature ("Hematocrit [Volume Fraction] of Blood (Lab-Test)"). It is important to find schema information that can tell which table or column is related to the user-requested feature.

1.Schema Linking and Guideline Generation : Feature Schema

Get all schema information related to the user-requested feature.

2.Feature Locating

Use LLM to check whether the user-requested feature exists in column location from the [Selected Schema]. In this case, LLM decides that user-requested feature does not exist in the column location.

3.Candidates Matching - Candidates Listing

LLM generates two SQL to list candidates from two tables since LLM from previous step selected two tables to search for the user-requested feature.

3.Candidates Matching - Target and Candidates Matching

Compare each candidate to the user-requested feature and list only the candidates that has higher similarity score than the user-defined similarity threshold score.

3.Candidates Matching - Target and Candidates Matching

After the initial comparsion process, we merge the remaining candidates into one list and compare them with the user-requested feature once again.

4.Final Code mapping Results

Merge matching result(s) which has higher similarity score(s) than user-defined similarity score threshold. Finally, we obtain the user-requested mapping code(s) for the target EMR database ("Hematocrit [Volume Fraction] of Blood (Lab-Test)" in SICdb).

📌 Application of EMR-AGENT

Integration Example

Use Code mapping Agent & Cohort Agent

Use each Agent for its role. Then get each schema information & guideline, feature matching results, and cohort SQL.

SQL generation

Use an LLM to generate an integrated SQL query that satisfies user requested conditions, including the event stream dataset and target time range.

Make final integration csv file

Excute integration SQL to target database. Then make user requested csv file.

Use LLM to judge whether the selected Schema information is sufficient to make SQL to extract user-requested [Cohort Selection] and [Features].
In this case, LLM think the selected Schema information is enough to make SQL. So, we pass other path in "SQL-based Observation".

Use LLM again to judge whether the selected Schema information is sufficient to make SQL to extract user-requested [Cohort Selection] and [Features].
In this example, LLM think we need more information to make correct SQL.
Thus, LLMs generates observation SQLs to gain additional information.

Execute observation SQLs to obtain extra information from Database.
Then, LLM decides whether the observed information already exists in the [Selected Schema] and [Schema Guideline] or it offers additional important information.

Use LLM to judge whether the updated Schema information ([Selected Schema] and [Schema Guideline]) is sufficient to make SQL to extract user-requested [Cohort Selection] and [Features].
With additional information, LLM think Schema information is now enough to generate SQL.

We then execute the generated SQL to obtain user-requested [Cohort Selection] with [Features] as a tabular format.
With the obtained table data, we compare our result with True csv file with our evaluation metrics.

Get definition schema information for the user-requested feature ("Hematocrit [Volume Fraction] of Blood (Lab-Test)").
It is important to find schema information that can tell which table or column is related to the user-requested feature.

Use LLM to check whether the user-requested feature exists in column location from the [Selected Schema].
In this case, LLM decides that user-requested feature does not exist in the column location.

Merge matching result(s) which has higher similarity score(s) than user-defined similarity score threshold.
Finally, we obtain the user-requested mapping code(s) for the target EMR database ("Hematocrit [Volume Fraction] of Blood (Lab-Test)" in SICdb).