AritmoLab · Policlinico San Donato

Role of AI in the Analysis of Unstructured Clinical Databases

How we turned a mix of structured and free-text clinical records into a research data platform — the AritmoLab platform experience.

AritmoLab A clinical data platform hosting cardiology data and analysis tools

Dr. Marco Pancotti - MultiPhysixLab Dr. Sara Paratico - I.R.C.C.S. Policlinico San Donato

“Multidimensional Characterization of Cardiac Arrhythmias: Role of Electrocardiology in the Artificial Intelligence Era”

San Donato Milanese, Milan, Italy · 2–3 October 2026

AritmoLab · Policlinico San Donato

Where we started - Four islands and four missing pieces

?Clinical Intelligencedashboards on the clinical history of the Unit and its patients

?Datawarehousethe single source of truth

?ML-ready datacohort tables, ready for model training

?Professional PortalAritmoLab — the grown-up Omics Portal

Missing Pieces

▸ click a system: how it was used — and what held it back · click a missing piece: what it would have given

AritmoLab · Policlinico San Donato

The plan

What we wanted to build

One platform, two destinations: the 360° patient portal and a research-ready warehouse. Built on open-source pillars, with AI coding agents wherever they helped. Next, we’ll look at the hardest part: unstructured data.

→

What we built

→

AI reads the clinical text: pathologies, procedures, drug-challenge outcomes

→

AI builds them on demand from plain-English questions (ThothII)

→

AritmoLab Data Warehousequeried for research

AritmoLab Portalmanagement & exploration

AI coding agents — Anthropic · OpenAI — used wherever they helped, 360° in the code Airflow · orchestration Superset · dashboards Django · portal scaffolding Authentik · auth — GSD LDAP

Here is the whole project on one slide. On the left, what already existed, three hospital data sources: (1) What existed: Cardioref, our electrophysiology records dataset, the genetic data coming from the labs, the ECG signals, and, in the future, other sources. On the right, what we built in AritmoLab: (2) a staging copy of all relevant Cardioref data, (3) an integration layer where the data is cleaned and normalized, (4) a star-schema warehouse, where the data are reorganized as facts and dimensions, and (5) research datamarts, generated from the data warehouse and presented through dashboards embedded in the portal. Everywhere you see the brain symbol, that's where AI works for us. 6 - The mappings that bring the sources in were themselves drafted by AI, then revised by humans 7 - At integration, AI reads the clinical text. 8 - At the end, AI builds the datamarts on demand from plain-English questions. That was the plan. And to build it, we used AI everywhere it helped — drafting configs, reading clinical text, and at the very end, producing the datamarts themselves. Next, we’ll look at the hardest part: unstructured data. My colleague, Sara Paratico,do will show you exactly how the text reading works. But first, the first step of the climb: the mappings.

AritmoLab · Policlinico San Donato

From free text to a research platform

The clinical truth lives in unstructured columns

“Il paziente riferisce sincope ricorrente; ECG basale con sopraslivellamento ST in V1–V3; test provocativo con flecainide positivo per pattern Brugada.”

EN“The patient reports recurrent syncope; baseline ECG with ST-segment elevation in V1–V3; flecainide provocation test positive for a Brugada pattern.”

SourcesCardioref · Genetic data
Omics Portal · ECG

→

Stagingraw replica

→

Integration3NF · text mining

→

Data Warehousestar schema

→

Martsdbt · Superset

four challenges to face · the answers come next

01

Volume without structuretwenty years of records locked in free-text columns

02

Ambiguous languagenegation · family history · bilingual shorthand

03

No shared ontologyevery system names conditions its own way

04

Proving reliabilityextraction must be demonstrably correct

outputs of the datamarts

Dashboardsclinical review on Superset

Machine Learningcohort tables for model training

Predictive Statisticsoutcomes & risk analysis

ThothII — natural-language → SQL over the DWH, builds the final datamarts

AritmoLab · Policlinico San Donato

What the text mining produced

Deterministic AI, audited numbers

58,438letters read

73,389pathologies extracted

10,908tests parsed

2,307Brugada patients

≈ 240letters / month

Letter readerevery discharge letter, Italian & English

Clinical matcherrecognises diagnoses, procedures, test outcomes

Context guardnegations & family history kept apart

Ontology sorterevery finding into its clinical category

Traceable. Every finding carries the version of the rules that produced it (pattern_version): any number can be rebuilt years later.

Audited. A new rule set goes live only after it proves ≥95% accuracy on 100 records reviewed by hand.

[DRAFT — Sara] I'll take you inside these numbers. We read 58,438 discharge letters — every single one, every night. From them the text miner extracted 73,389 pathology records, classified into our clinical ontology. It parsed 10,908 drug-challenge tests, distinguishing the therapy from the actual test. And at the end of the chain: 2,307 patients with a confirmed Brugada pattern — a cohort nobody could have built by hand. This is not a one-off migration: the pipeline runs every night, and today it processes on average two hundred and forty letters a month. Four simple pieces do the work: a letter reader for the Italian and English text, a clinical matcher that recognises diagnoses, procedures and test outcomes, a context guard that keeps negations and family history apart, and the ontology sorter that files every finding into its clinical category. The key word here is deterministic: no black box. Every number can be traced back to the rule that produced it.

AritmoLab · Policlinico San Donato

Clinical NLP

Reading clinical text is not keyword matching

Negation — “fibrillazione atriale esclusa”, “non FA” (“AF ruled out”, “no AF”): the rule scans a window around every match before deciding
Family ≠ patient — “padre con FA” (“father with AF”) is attributed to the family member, not to the patient
Two languages — every pattern matches IT and EN forms: fibrillazione atriale / atrial fibrillation
Abbreviations & noise — FA, f.a., “TA 140/90” (blood pressure, not a diagnosis)
One field, many statements — the text is split into clauses before matching

what the rules seeexamples from the corpus

“padre con fibrillazione atriale”
“father with atrial fibrillation”
  → patologia: FA · attribuzione: familiare
pathology: AF · attribution: family

“fibrillazione atriale esclusa”
“atrial fibrillation ruled out”
  → patologia: FA · negato
pathology: AF · negated

“test provocativo con flecainide
  positivo per pattern Brugada”
“flecainide provocation test, positive for Brugada pattern”
  → test: flecainide · esito: POSITIVO
test: flecainide · outcome: POSITIVE

AritmoLab · Policlinico San Donato

The clinical ontology

Two tiers, one clinical order

TIER 1 · arrhythmic11

AFFABrugadaFlutterATTAAVNRTTRNPSVTWPW / TPSVVTTVVFFVVentricular ectopyExtrasistolia V.SyncopeSincopeLong QTQT lungo

TIER 2 · structural5

AV blockBlocco AVBundle branch blockBlocco di brancaCardiomyopathyCardiomiopatiaHeart failureScompensoValvular diseaseValvulopatia

01

Order encodes clinical precedence — “Brugada” is matched before “TV”, so “substrato per TV” (“substrate for VT”) can't mask a Brugada pattern

02

Synonyms live inline — FA / f.a. / fib. atriale / atrial fibrillation → one canonical label

03

Versioned like software — semver for the pattern library, pattern_version on every extracted row

The output: text becomes recorded data

01

Quantitative data on the recordsevery procedure and implant the text analysis reads is written back as structured, quantitative values on the record that describes it

02

Straight into the DWH flowthese records enter the data-warehouse generation like any other source

03

As if typed at the visitthe data lands exactly as if clinicians had keyed it in themselves during the visits

[DRAFT — Sara] Extraction needs a target vocabulary — that's the ontology. Tier 1 holds the eleven arrhythmological categories that matter most for our research; Tier 2 holds five structural conditions. The order of the rules is itself clinical knowledge: Brugada patterns are tested before TV, because "substrato per TV" often appears in Brugada reports and would otherwise mask the diagnosis. The ontology is versioned like software: a semantic version for the pattern library, stamped on every extracted row. When we add a synonym or fix a rule, the change is traceable — and the data can be rebuilt. And this is the output of the whole work: reading a letter writes structured, quantitative values back onto the records that describe the procedures and implants it contains — and those records enter the warehouse generation exactly as if the clinicians had typed them during the visits. Text becomes data, indistinguishable from bedside data entry. Sara: review the category list and the Italian labels before final. Labels are now English-first (audience is mostly foreign) — please confirm the EN terms, especially PSVT as the umbrella for WPW/TPSV and AT/AVNRT for TA/TRN.

AritmoLab · Policlinico San Donato

Validation

Trusting the text is a process, not a promise

Quality gateManual comparison checks procedure accuracy. Pathology coverage and clinical correctness are assessed separately.

We set a 95% procedure-accuracy target, against 100 manual reviews. The 85% pathology target measures coverage, not diagnostic accuracy.

Finding a disease name in a letter is only the first step. We apply explicit clinical criteria to decide which patients belong in the analysis.

Version 1.3.1 corrected missed negations in roughly 900 Brugada records, with regression tests protecting the fix.

Negated and family findings retain their context. Research datasets filter them explicitly, so preserving a finding does not mean counting it as the patient’s diagnosis.

We can reprocess the archive quickly, inspect the rules behind each result, and reproduce the same extraction with the same rules.

AritmoLab · Policlinico San Donato

The portal, today

AritmoLab — a quick tour

Select a screen to enlarge · Follow the tour from 1 to 7

The home page summarises around 57,000 patients, by age, sex and geographical origin. It is the starting point for exploring the archive.

Search filters help us find a patient or study participant, open their record, or export the results.

The profile brings demographic and clinical fields together, with access to procedures, devices, diagnostic examinations and genetics.

A dated timeline brings together clinical notes, discharge letters and procedures, retaining the source of each event.

Here, an ablation record shows the treated arrhythmias, procedural details, recorded complications and conclusions.

We then move from individual records to dashboards covering departmental activity, procedures, devices and genetics.

The funnel separates text mentions, filtered mentions, confirmed cases and ablation outcomes. Other charts describe sex, age, annual diagnoses and the timing of pre- and post-assessments.

AritmoLab · Policlinico San Donato

All good? Not yet.

The warehouse speaks SQL. Research needs more.

The gapTwenty years of data, one warehouse — and no fast road from a research question to an answer.

AritmoLab · Policlinico San Donato

ThothII, step by step

From question to datamart — the app

Select a screen to enlarge · Follow the tour from 1 to 12

From a research question to SQL

The task has changed. We are no longer extracting structured, coded values from the text within clinical records. We are now starting from a natural-language request to retrieve the records that contain the relevant values.

Research questions are often difficult to express clearly and unambiguously, and their clinical concepts do not map directly to the underlying database structure. As a result, writing the right SQL query can take hours, with repeated testing and refinement before it accurately reflects the intended research question.

Clarifying the question with the researcher

1. Workflow phase. At the top, the phase indicator shows where we are in the process. Here, phase one is highlighted: clarifying the research question.

2. AI working time. The timer measures how long the AI has been working, excluding the time the human reviewer spends considering the options and making decisions.

3. Model activity. On the left, we can follow the AI's running explanation of its analysis: the interpretations it considers, the evidence it consults, and the rationale for its proposals.

4. Proposed interpretations. In the centre, the AI asks the researcher to choose between alternative interpretations. Here, the question is how to identify an ablation for atrial fibrillation in the database. This choice determines which patients enter the study.

5. Reviewer actions. The reviewer can select a proposed option, or use Go back to revisit the previous step, Exit to stop the current workflow, or Other — specify to describe a different interpretation in free text.

From clarification to an agreed study question

Bringing the decisions together. The AI combines the original request with the researcher's answers into an explicit study definition. It records what we mean by each clinical concept, which patients to include, the time window, and the result we want.

The clarified question. In this example: how many distinct patients had their first recorded ablation for atrial fibrillation between 2020 and 2023? We identify the procedure from the treated pathology, and find each patient's first AF ablation across the entire available database history before applying the date filter.

Making the interpretation actionable. The summary links these choices to the relevant database fields and selection rules, and displays the checks completed during clarification. These agreed criteria guide the subsequent schema linking and SQL construction.

Human confirmation. The researcher reviews the consolidated definition. Save and proceed confirms it and closes phase one; Reject sends it back for revision.

Finding the data needed to answer the question

Linking clinical meaning to data. We are now in phase four, schema linking: identifying where the information needed to answer the agreed question is stored. Tables group related records; columns hold specific details, such as a patient identifier, a procedure date, or the condition treated.

Proposed tables. The AI presents candidate tables and explains why each is relevant. Here, one table provides the ablation episodes and their dates; another identifies the pathology treated, allowing us to distinguish atrial fibrillation ablations from other procedures.

Selecting the columns. The column controls let the reviewer inspect and adjust the fields selected for the query. We need the information required to identify patients, recognise the relevant procedures, and apply the agreed time criteria.

Review before proceeding. The researcher and a technical reviewer can check this mapping together, adjust the selection, and confirm it. This establishes which data will support the SQL query; the relationships between the selected tables are reviewed next.

Schema linking complete: from clinical meaning to database structure

What schema linking means. Schema linking connects the concepts in the clarified research question to the database: which tables contain the information, which columns represent each concept, and how records from different tables must be connected.

Our clinical example. Here, we connect the treated pathology to the corresponding ablation episode, associate that episode with its date and patient, and specify the rules for identifying each patient's first recorded AF ablation and applying the 2020–2023 window. The intended result is a count of distinct patients.

What completion means. These choices are now consolidated into a documented mapping, with the relationships, selection rules, and validation checks shown for review. We have an explicit specification of where the answer will come from and how the relevant data fit together.

The final approval. By selecting Save and proceed, the reviewer approves this mapping for the next stage: planning and building the SQL query. Query execution and verification of the resulting patient count still follow.

CTEs: building the query step by step

CTE stands for Common Table Expression. It is a named intermediate result within an SQL query.

CTEs break a complex research question into smaller, logical steps—for example, identifying AF ablations, finding the first procedure for each patient, and selecting the study population.

This makes the query easier to understand, check, and modify, helping us verify that each step reflects the intended clinical criteria.

Reviewing a CTE: purpose, SQL, and results

Purpose and position. Each CTE is presented as a reviewable step. At the top, we see its name and position in the sequence: here, the first of three. A short explanation describes its clinical purpose and the reasoning behind the selection rules.

The SQL implementation. The code shows how that purpose is translated into database operations. In this example, it connects the treated pathology to the ablation episode and selects AF ablations, returning the patient identifier, episode identifier, and procedure date.

Tests and a data preview. The screen reports the test status and execution time, followed by a preview of the returned records. The ten rows shown are a limited preview, not the total study population. Successful execution still requires a check that the results make clinical sense.

Human review. The reviewer can compare the explanation, code, and sample data before choosing Save and proceed or Reject. This makes each intermediate step inspectable before it contributes to the final query.

Titolo8

testo8

Reusing the query: daily datamarts or research on demand

Once the query generation and review workflow is complete, the validated SQL query can be reused beyond the current session.

Daily datamart generation. The query can be integrated into the broader ETL pipeline and scheduled to run every day. This allows the datamart to be rebuilt or refreshed systematically as new source data become available, using the same agreed selection rules.

Reuse by researchers. Alternatively, the query can simply be saved as an SQL file and made available to researchers, who can inspect it, run it when needed, or adapt it for a subsequent study.

In both cases, the workflow produces a reusable query that captures the reviewed interpretation of the research question.

Saving clinical clarifications for future queries

What we retain. Clarifying a research question can produce knowledge that is useful beyond the current study: for example, an agreed interpretation of a clinical term or how a procedure is represented in the local data.

The researcher chooses. At the end of the workflow, ThothII presents candidate clarifications for reuse. The reviewer selects which ones to save as shared knowledge for the workspace.

How this helps next time. When a related question is asked, ThothII can retrieve these clarifications and propose them to the reviewer. The reviewer checks whether they apply to the new question before using them. This helps avoid repeating the same clarification work while keeping each study's interpretation under human control.

A saved session documents how the result was reached

At the end of the workflow, ThothII finalizes a session that brings together the generated SQL statement and the documented process that led to it.

The session preserves the research question, its agreed interpretation, the mapping to the database, the intermediate query steps, and the recorded validation results.

Human involvement is captured through the recorded clarifications and review decisions: what the reviewer selected, approved, or rejected along the way. These records document how the interaction between the system and the researcher shaped the final query.

Researchers can revisit the session to inspect the SQL and understand the choices behind it. This provides a traceable record of how the original question became the final result.

Time and cost for this example. The AI processing took less than five minutes, excluding the time spent on human review. Using DeepSeek V4 Flash, the estimated model cost for this run was about five cents.

Expert supervision and deployment options

Supervision requires knowledge of the data. The workflow must be supervised by someone who understands the meaning and content of the database tables and fields. AI can make plausible guesses about what a field represents or how records should be connected, and these guesses can become hallucinations. The reviewer's role is to challenge those assumptions and check them against the actual data and its clinical meaning.

The researcher defines the dataset. Human judgement is essential to decide which information the study needs, which records meet the required quality criteria, and which time windows and temporal rules should apply. The responsible researcher must confirm these choices so that the resulting dataset addresses the research question. Successful SQL execution alone does not establish that the dataset is suitable for the study.

Server or authorised workstation. At Policlinico San Donato, ThothII runs on a server. The application can also be installed on the PC of a qualified staff member who is authorised to access the database remotely. The application runs on that workstation, while the database server executes the SQL through the authorised connection.

A local deployment option. Open models such as Qwen3.8-27B or Gemma 4 26B A4B are candidates for running the AI component on premises. Their suitability for this workflow should be assessed on representative research questions, including the quality of the generated SQL and the reliability of the review steps.

Hardware within reach. With quantized models, a compact server equipped with a suitable GPU is a practical deployment option. A GPU budget of a few thousand euros is a planning target; the required memory and final cost depend on the model, context length, and number of concurrent sessions.

Where the query runs. SQL execution takes place on the internal database server through controlled application code. The language model helps construct and review the query; the database engine executes it.

Keeping model processing local. Hosting the session model on premises allows its prompts and responses to remain within the organisation. With an external model, the information included in prompts and tool results must be checked and filtered to prevent sensitive data from leaving the environment.

Model references: Qwen3.8-27B model card; Gemma 4 models and memory requirements.

AritmoLab · Policlinico San Donato

From datamart to discovery

One datamart — many questions answered

Multivariate analysis[SVG chart — next step]

Machine learning[SVG chart — next step]

[Illustrative data, modeled on published arrhythmology predictors — Brugada focus]

AritmoLab · Policlinico San Donato

Questions?

Thank you

Want the deep dives? The technical walkthroughs of the text miner, the mapping agents and ThothII are coming as videos on our Substack.

Dr. Marco Pancotti - MultiPhysixLab Dr. Sara Paratico - I.R.C.C.S. Policlinico San Donato