Home / Case studies / AI Natural Language to SQL for Public Health Data
Case study · Public health · Generative AI
AI Natural Language to SQL for Public Health Data
A US public health analytics organization pulled weekly influenza data by hand, one region at a time. Brainy Neurals built a natural language to SQL layer that uses a language model to turn plain English questions into database queries. An automated pipeline collects, cleans, deduplicates & loads the data into one warehouse on a schedule, replacing the manual downloads staff used to do. Now the data refreshes on its own, & non-technical staff get answers in seconds without writing SQL.
On a schedule
Data refreshes by itself
Plain English
How staff ask questions
Seconds
Time to each answer
Published October 2026
At a glance
What problem did this solve?
A US public health analytics organization pulled weekly influenza data by hand. Collection was slow, & every answer past the raw file waited on someone who could write SQL.
What did Brainy Neurals build?
Brainy Neurals built an automated data pipeline for a US public health analytics organization, plus a natural language to SQL layer. The pipeline loads clean data, & the layer turns plain English questions into queries.
What changed after it went live?
Collection, cleaning, deduplication & loading now run on a schedule with no downloads. Non-technical staff ask in plain English & get answers back in seconds.
Who else could use this?
Any team that pulls data from scattered portals & waits on analysts fits this pattern. Finance, logistics, manufacturing & retail teams all qualify.
Engagement facts
| Field | Detail |
|---|---|
| Industry | Healthcare & life sciences |
| Client type | US public health analytics organization |
| Engagement | Data platform & natural language analytics |
| Timeline | Not disclosed |
| Capabilities | Data automation & generative AI |
| Delivery model | Project-based delivery |
Why couldn’t the team query its data?
A US public health analytics organization couldn’t query its influenza data, because collection ran by hand & reading it took SQL. Natural language to SQL could fix the reading part once clean data arrived by itself.
The organization tracks influenza surveillance data across a whole country & needs one current place to hold the numbers. Its source data lived on a public government health portal that only allowed manual downloads.
- One file at a time. Each cycle, a person picked every category on the portal by hand & downloaded each one as its own file.
- Retyped by hand. Staff unzipped each archive & retyped it into spreadsheets, so errors crept in.
- Duplicates everywhere. New records were hard to tell from old ones, so the store held numbers that disagreed.
- One analyst gate. Every business question turned into a ticket for the one analyst who could write the SQL query behind it.
Finding & preparing scattered data is the slowest part of most analytics work, according to an interview study of enterprise analysts[1]. The people who can do that work become a bottleneck the rest of the team waits on. That wait is the gap our generative AI applications work closes.
Why do common approaches stall?
Common approaches stall because each one fixes a single part of the problem & leaves the rest in place. Four routes look reasonable at the start, & the first three each hit a wall.
| Approach | What it gets right | Where it stops | Who it still suits |
|---|---|---|---|
| Manual downloads & spreadsheets | No new tools, full control | Repeats every cycle | One-off pulls, tiny datasets |
| Off-the-shelf BI dashboard | Fast charts on clean data | Still needs someone to model the data | Teams with a ready warehouse |
| Hire more analysts | Real answers, human judgment | The bottleneck just moves | Deep one-off investigations |
| Pipeline plus a language layer, our route | Fresh data, plain English answers | Weeks of pipeline & grounding work | Teams asking new questions often |
Published research points in the same direction. In one study, a natural language interface cut query time by 10% to 30% against a standard SQL tool. Accuracy rose from 50% to 75% in the same test[2].
How we built natural language to SQL
Brainy Neurals built the platform in two halves that meet at one data warehouse.
The first half is an automated pipeline that collects, cleans, deduplicates & loads the data on a schedule. The second half answers a plain English question from that same warehouse.
Because both halves share one warehouse, every question a person asks reads the very latest data.
Collection, cleaning, the warehouse & the question layer all sit inside one platform.
The first design choice was how to keep data honest across cycles. We gave every record a fingerprint, so a row already captured gets spotted & skipped instead of loaded twice. We also archived every raw source file, so the store can be rebuilt & checked against its origin.
The second choice was how a question finds its answer. A hosted language model reads the intent, & vector search matches loose place names to official regions. The model then picks the right tables & writes the query, so the person asking never sees SQL.
The stack we shipped
The stack we shipped gives each layer one job, chosen for how well it does that job at production scale. The same pipeline spine shows up in our AI workflow automation builds, fed by other sources.
Collection & storage
A browser automation robot pulls every category from the portal on a schedule, with nobody watching.
Rule-based cleaning fixes data types & trims noise in one standard pass.
Cloud object storage archives every raw source file for later audits.
We ruled out manual downloads & spreadsheet copy-paste, because both methods repeat by hand every single cycle.
Warehouse & matching
A central cloud data warehouse gives every view of the data one query-ready home.
A fingerprint hash blocks duplicate & conflicting rows.
Vector search over region names maps vague or partial terms to the official regions on file.
We ruled out scattered files, spreadsheets, eyeballed checks & exact-string lookups, because each one misses too much.
Language & delivery
A hosted large language model reads the intent of each question & writes the query.
An authenticated REST API returns answers in seconds, with caching.
We ruled out hand-written SQL for each question & a person on call for reports, because neither one scales.
How does one question become an answer?
One plain English question passes through six stages between the person asking & the answer coming back. None of those stages asks that person to know SQL.
- A user types a question, such as one about flu activity in a region over a chosen season.
- A hosted language model works out the question’s intent, place, time & measure.
- Vector search matches vague or partial place names against a store of official names & returns the right one.
- The model picks the tables & columns that hold the answer.
- The system writes the query behind the scenes, then reads the result from the warehouse.
- The answer comes back through an API in seconds, with no query written by the person who asked.
What broke & how we fixed it
Three problems broke the build, & each one needed its own fix. Duplication hit first, because each cycle brought overlapping data with no reliable way to spot repeats.
The schema came next, spread across many tables with cryptic names. Loose language came third, because people name places freely & exact-match lookups missed most of them.
None of this was unusual for a build on real data. On messy databases, the hardest error is linking a question to the right tables, & strong models still trail human accuracy without grounding[3].
These are the weeks when clients choose to hire AI developers rather than learn it all slowly.
Duplication
Each cycle brought overlapping records, so the same numbers landed twice & disagreed with each other.
Our fix gives every record a fingerprint built from its own values, so a row seen before gets skipped.
Schema
A plain question rarely mapped to one table, & early queries pulled from the wrong place.
Now the model reads a clear map of the tables & picks the right ones before writing anything.
Language
Exact-match lookups missed most of the ways people actually name places.
A vector store of official region names now matches loose phrasing to the right area.
A dedup fingerprint is an old trick borrowed from storage systems. Finding problems like these early is the job of an AI proof of concept, before anything gets promised.
What changed after go-live?
Brainy Neurals shipped the pipeline & the natural language to SQL layer into production for the public health team. Fresh surveillance data lands in the warehouse each cycle. Staff across this AI in healthcare build ask in plain English & read each answer through an API.
| Dimension | Before | Now |
|---|---|---|
| How collection runs | A person downloads each category by hand | A robot pulls every category on a schedule |
| Data quality | Duplicates & retyped errors crept in | Fingerprints block duplicates before they load |
| Who can get an answer | Only staff who write SQL | Anyone who can ask in English |
| Time to an answer | A ticket, then a wait for the analyst | Seconds, straight from the API |
| Source of truth | Files & spreadsheets, scattered | One warehouse, refreshed each cycle |
We haven’t published a speed or volume figure, though the client reports both moved the right way. Until those figures are measured, this page won’t print them.
Day to day, nobody downloads surveillance files by hand anymore, & nobody writes SQL just to read them. Every raw file stays archived, so any figure can be traced back to its source.
Want this pattern running on your data?
Tell us which questions wait on an analyst today, & we’ll map the pipeline your data would need. If you’re unsure the data is ready, start with the AI readiness assessment.
What we would do differently
We’d change four things about how this build started, & each one now shapes every new build.
Fingerprint records from day one
We added deduplication after duplicates had already muddied the store, which forced an unbudgeted cleanup.
These days the fingerprint goes into the very first load.
Map the messy language early
We only learned how loosely people name places once real questions arrived.
We now collect that phrasing at the start, so real usage shapes the matching store.
Test on a full cycle
A pipeline that looks clean in a demo can still fail on a full cycle’s mess.
A whole reporting cycle now runs on real data before anyone calls the build done.
Keep raw files from the start
Archiving every source file felt like overhead until the first time a number was questioned.
The raw archive now comes first, at the start of every build.
Where else does this pattern fit?
The pattern fits wherever data sits in scattered places & the people with questions can’t write the query. It collects data on a schedule & keeps it clean in one warehouse, so plain English questions get answers straight from it.
Finance
Analysts wait on SQL for every market or risk question.
The same layer answers them, with tighter access rules & full audit trails.
Logistics
Rate & customs data sit across many separate portals.
The build adds more source connectors, plus matching for shipping lanes.
Manufacturing
Quality & line data live in separate plant systems.
Time-series joins & a schema for each plant carry the port.
Retail & e-commerce
Sales & inventory data spread across many platforms.
Several source APIs & product-code matching handle the joining.
Insurance
Claims questions queue up behind a busy data team.
Anything that identifies a person gets careful handling in the build.
Porting the pattern takes new source connectors, a matching store, a schema map & a full-cycle test on real data.
Questions buyers usually ask
Can AI answer questions from a database in plain English?
Yes, a natural language to SQL layer can answer most everyday questions from a clean, well-described warehouse. It maps the question to the right tables & writes the query, so nobody touches SQL.
What is text-to-SQL, in plain terms?
Text-to-SQL turns a plain English question into a database query. A language model reads what you meant & picks the tables that hold the answer. Then it writes the SQL for you.
How is this different from a normal BI dashboard?
A dashboard answers only the questions someone built into it in advance. A natural language layer answers new questions on the spot, because it writes a fresh query each time.
How long does a build like this take?
Brainy Neurals usually stands up a working proof of concept on your own data in a few weeks. Collection, cleaning, deduplication & the question layer each get a pass, then production follows.
How much does a build like this cost?
The cost depends on how many sources you pull from & how messy the data is, plus what you already run. We scope it from a short conversation & a look at your data, then quote a fixed price. An AI readiness assessment tells you first whether your data can carry it.
Is it safe to let a model query production data?
Yes, it’s safe with guardrails in place. The layer reads through a controlled path, & every request is authenticated. Public health data carries extra duty of care, so raw source files stay archived & any answer traces back to its origin.
What does your team need to ask?
Tell us which questions wait on an analyst today & where the data sits now. The person who would architect the build reads every message & sends one reply.
Services behind this case study
Six Brainy Neurals services carried this build from the first download to the production answer.
Generative AI applications
The question layer that turns plain English into a query & a readable answer.
RAG & vector search
A vector database that maps loose, real-world phrasing to the right official terms.
AI agents & workflow automation
Unattended data collection & loading that runs on a schedule without a person.
Hire AI developers
Data & AI engineers who extend your team through the weeks when the pipeline fights back.
AI proof of concept & MVP
A few weeks to prove the pattern on your own data before anything is promised.
AI in healthcare
Data & analytics systems for healthcare & public health teams that depend on trustworthy numbers.
Our AI consulting services help pick what to automate first. An AI readiness assessment shows whether your data can carry a build like this. Our AI solutions by industry show where the pattern already runs, & our AI development services cover the rest.
Similar case studies
Another Brainy Neurals healthcare build put generative AI to work under clinical review.
AI Diet Assistant for Gastroenterology
Clinical dietary guidance generated under review gates, now live in a healthcare setting.
All Brainy Neurals case studies
Every published Brainy Neurals case study, collected on one page.
Cite this case study
Shah, Rushabh. AI Natural Language to SQL for Public Health Data. Brainy Neurals, September 2026. https://brainyneurals.com/case-studies/natural-language-data-analytics/
Sources cited on this page
[1] Kandel S, Paepcke A, Hellerstein JM, Heer J. Enterprise Data Analysis and Visualization: An Interview Study. IEEE Transactions on Visualization and Computer Graphics. 2012, 18(12), 2917-2926. DOI 10.1109/TVCG.2012.219
[2] Ipeirotis P, Zheng H. Natural Language Interfaces for Databases: What Do Users Think? IEEE Transactions on Knowledge and Data Engineering. 2025. arXiv:2511.14718
[3] Li J, Hui B, Qu G, et al. Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs. NeurIPS 2023. arXiv:2305.03111