Iurii Iurchenko Puts Data Quality First in Healthcare AI Agents

The question sounded straightforward: How many distinct food recalls were distributed to Colorado? In Iurii Iurchenko’s demonstration, an AI data agent returned an incorrect answer because it selected the wrong table. A better-configured version produced the intended result after he clarified which table to use for questions about state distribution.

That example captured the central message of his HealthDataCon 2026 presentation, Conversational Data: AI Data Agents, Their Benefits, Limits, and Risks. Asking questions in ordinary language can make analytics more accessible. Reliable answers still depend on data engineering, explicit definitions, appropriate permissions and sustained testing.

Iurchenko, a senior data engineer at Life Line Screening and principal of Data Assets LLC, used Microsoft Fabric to explain the approach. To demonstrate it without exposing private healthcare information, he built a personal project using FDA food recall data. The openFDA service provides publicly releasable enforcement records from the agency’s Recall Enterprise System and updates them weekly.

A new way to explore data

“Data agents give us the opportunity to talk with data,” Iurchenko said. He described a conversational layer that interprets a question, generates a query, retrieves results from selected organizational sources and presents an answer.

Microsoft’s Fabric documentation describes that process across supported sources, using languages such as SQL, DAX or KQL. The distinction matters: the agent is working with a defined data environment, rather than simply answering from general knowledge.

Iurchenko contrasted this experience with a prepared business intelligence report. Reports provide established views, measures and filters that teams can revisit. A conversational agent allows additional questions and follow-up exploration without requiring a developer to anticipate every interaction. He presented these capabilities as complementary.

Potential healthcare uses included exploring waiting times, patient survey results, missed appointments and staff utilization. He favored bounded operational analysis as a starting point and urged greater scrutiny as consequences increase. Even an operational question requires attention to privacy and to how its answer might influence access or staffing decisions.

His boundary was clear: an analytical assistant should support people’s decisions. A fluent answer does not establish that a tool is appropriate for autonomous diagnosis, treatment or other critical patient decisions. Organizations must first identify the problem they want to solve and why an existing report is insufficient.

Build the foundation first

Much of the presentation concerned work that happens before an agent is configured. Iurchenko argued that a weak data platform makes a dependable conversational experience difficult to achieve.

He organized that work around three layers, consistent with Microsoft’s medallion architecture. Bronze preserves source data as received. Silver cleans, deduplicates and standardizes it. Gold organizes curated information for business use. These layers separate responsibilities and make it easier to rebuild downstream outputs when requirements change.

In healthcare, the cleaning work can include reconciling codes and identifying whether differently named statuses actually represent the same event. A screening date and a visit date may both be valid fields while answering different questions. Their meanings need to be understood before an agent chooses between them.

At the gold layer, Iurchenko recommended organizing events and their descriptive context clearly. Microsoft’s modeling guidance explains the corresponding star schema: fact tables hold events or observations, while dimension tables describe entities used to filter and group them. In his example, recall facts were connected with the information needed to analyze them.

He also emphasized documenting how source fields become target fields, including transformation rules and edge cases. Agreeing on that mapping gives engineers and business owners a shared reference before implementation. A diagram explains relationships; a detailed mapping explains what happens to individual values.

Recoverability belongs in the same foundation. Iurchenko called for pipelines that can be rerun safely after a failure without creating duplicates or corrupting results. Retaining raw inputs, monitoring freshness and checking quality help teams distinguish an agent’s reasoning problem from an upstream data problem.

Teach the agent how to choose

Iurchenko described four components of an agent: its data source, general instructions, source-specific guidance and example queries. Each addresses a different question, from the role the assistant should perform to which table supports a particular calculation.

His most practical instruction was to explain when information should be used. A label saying that a table contains patient data leaves important choices unresolved. Guidance that distinguishes the table for encounters from the table for patients, and specifies which date governs a measure, gives the agent a clearer decision path.

The slide shorthand was “Use it when…” Iurchenko compared this with orienting a new colleague: explain the task, the relevant source and the circumstances in which an alternative is appropriate. His Colorado recall example showed how a missing rule about table selection could produce an apparently credible result.

Examples make that guidance concrete. Microsoft’s query guidance pairs natural-language questions with corresponding SQL or KQL and checks examples against the selected source’s schema. Such examples can clarify joins, filters and calculations, but the examples themselves need review for ambiguity and conflicting definitions.

Iurchenko also recommended instructions about response style and uncertainty. An agent should ask when a question is ambiguous, make consequential assumptions visible and provide a concise answer before additional detail. He described receiving lengthy responses that made simple questions harder to resolve. Clear presentation is part of usefulness, alongside accuracy.

Put security below the prompt

Another failure mode arises when teams try to create one universal agent with access to everything. Iurchenko warned that convenience can expand the information exposed through a conversational interface.

His slides located security in the data platform. Microsoft’s permission guidance states that Fabric agents honor underlying user permissions, including row- and column-level security. Sharing an agent does not, by itself, grant access to its underlying sources. Teams still need to configure those permissions correctly and test the experience of different user roles.

Read-only querying addresses the ability to change data; it does not establish that every answer is correct or every authorized disclosure is appropriate for the task. Iurchenko’s recommendation was to narrow the domain, identify an owner and expose curated information suited to the intended questions.

The accuracy risk extends beyond security. The NIST generative-AI profile identifies confabulation, in which a system confidently presents erroneous information. Iurchenko illustrated practical routes to a wrong answer: misunderstanding a question, choosing an unstated assumption, using the wrong formula or selecting an unsuitable source.

Keep testing after launch

Iurchenko treated testing as a substantial part of implementation. Teams should ask the questions stakeholders will actually pose, including ambiguous wording and difficult cases, then compare the answers with independently established results. An attractive response is insufficient evidence that the underlying calculation is right.

Microsoft’s evaluation tools support datasets of questions and expected answers, along with diagnostic information about an agent’s execution. These capabilities provide a mechanism for finding errors and assessing changes; they still depend on the quality and coverage of the test set.

Iurchenko recommended refining definitions, instructions, examples and source data based on observed failures. The work continues after release because data structures, business requirements and provider models can change. A staged rollout and regular review help expose behavior that a successful demonstration may have missed.

He also asked organizations to consider operating costs and the effort required to maintain the platform. The value case depends on useful answers, manageable verification work and sustainable processing costs. His closing slide offered a concise standard for the agent’s role: “Helps people decide, does not decide.”