How I Designed an Agentic Healthcare Analytics Workflow

PII-Safe Publication Note

This report is a rewritten portfolio version of an academic project. It does not reproduce the raw submission, source data, screenshots, account details, personal names, emails, phone numbers, or institution-specific submission metadata. The emphasis is on system design, trade-offs, and transferable engineering judgment.

Executive Summary

The project explored how a healthcare analytics assistant could help clinical and research users ask questions over structured health data without hiding the analytical path behind a black-box response. The core design used a multi-agent workflow: one agent interprets the question, another maps the request to a data schema, another proposes SQL or statistical operations, and review steps check whether the output should be revised before a final answer is shown.

The main portfolio value is not simply that the system uses large language models. The stronger signal is the architecture around them: schema grounding, query traceability, human review checkpoints, privacy boundaries, and result explanations that make the analytical process inspectable.

Portfolio Signal Snapshot

This section is written for fast recruiter review and machine parsing. It foregrounds the technical surface area, architectural judgment, and risk controls without overstating deployment maturity.

Problem Context

Healthcare datasets are often structured, relational, and highly sensitive. Analysts may understand the clinical question but not the exact schema. Technical users may understand the database but need domain clarification before writing safe queries. A useful assistant therefore has to do more than generate SQL: it must clarify intent, ground terms to known fields, expose assumptions, and preserve auditability.

Sanitized Architecture Diagram

The original report included a high-level architecture view. The public portfolio version below recreates the same design idea without showing private schemas, source screenshots, client references, or raw clinical examples.

Curated Figure Gallery

These visuals combine light-background recreations of the core architecture with selected extracted planning graphs from the original capstone materials. The public version excludes raw data tables, report cover pages, institution-specific UI screenshots, and research-paper screenshots.

Short Demo Clip

This silent walkthrough compresses the architecture into a 16-second reviewer-friendly path. It is a storyboard demo, not a recording of private data or a deployed clinical system.

Research Connections

These source cards connect the portfolio architecture to published agent-design ideas without copying figures whose reuse rights are unclear.

Cite-Only Source

Transformer foundation

Source: Attention Is All You Need, Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N. Gomez, Lukasz Kaiser, and Illia Polosukhin, 2017. License note: arXiv non-exclusive distribution license; no external figure copied. Link.

Connection: cited as background for Transformer-based language models, not presented as a visual asset in this portfolio.

No figure reused

Analytical Objectives

• Convert natural-language research questions into structured analytical tasks while preserving the user's intent.
• Use schema and vocabulary grounding before query generation, so the assistant does not invent fields or use unsupported concepts.
• Generate SQL and statistical steps that can be inspected, rerun, or corrected by a human reviewer.
• Separate reasoning, querying, charting, and answer composition into smaller units that are easier to test.
• Keep the public portfolio version focused on architecture and safeguards rather than private data or unverified deployment claims.

Technical Notes From Source Report

System Design

1. Question Intake

The first step classifies the user question by analytical type. Examples include cohort counting, variable comparison, trend analysis, descriptive statistics, and chart requests. The workflow should also detect when a question is underspecified and ask for clarification rather than forcing a query.

2. Schema Grounding

The assistant maps natural-language concepts to known tables, fields, and controlled vocabulary where available. This grounding step is critical because a plausible answer is not useful if it rests on a fabricated column or an invalid join path.

3. Query Planning

A planning agent decomposes the request into operations such as cohort selection, filtering, joins, aggregation, and statistical tests. The plan becomes an intermediate artifact that can be reviewed before execution.

4. SQL Generation and Validation

The SQL component produces a query from the grounded plan. Validation checks should confirm that tables exist, joins are explainable, filters match the user's intent, and the query avoids unsupported fields.

5. Analysis and Visualization

Once the structured result is available, a tool layer can calculate descriptive statistics or generate charts. The final response should include the answer, the method used, and any limitations that affect interpretation.

6. Human Review

Human-in-the-loop checks are included for high-risk or ambiguous outputs. This is especially important for healthcare analytics, where confident language can create false authority if the underlying query is wrong.

Implementation Decisions

• Agent separation: Separate agents reduce the chance that one prompt has to perform every task at once. This makes failures easier to isolate.
• Traceable intermediate outputs: Intent, schema mapping, query plan, generated SQL, and final answer should each be stored or displayed for audit.
• Guarded generation: The system should treat schema references as constraints, not suggestions. Unsupported fields should trigger revision.
• Review-first framing: The assistant is positioned as an analytics copilot for structured exploration, not as a diagnostic or clinical decision system.

Decision Framework

My design thinking centered on a simple rule: use LLMs where ambiguity exists, and deterministic code where correctness can be enforced. The table and chart below make those trade-offs explicit.

Evaluation Approach

The strongest evaluation strategy for this type of project is multi-layered. Instead of grading only the final natural-language answer, the system should be checked at each stage where an error could enter the workflow.

Limitations

• An LLM can produce fluent explanations even when a query plan is flawed, so validation cannot depend on wording quality alone.
• Schema grounding works only as well as the available data dictionary, metadata, and domain concept mapping.
• The public version intentionally omits raw data and deployment details, so it should be read as an architecture case study rather than a production performance report.
• Healthcare analytics requires domain review before results are used for research, operational, or policy decisions.

Recommended Next Improvements

• Add a test set of sanitized natural-language questions with expected query plans and SQL patterns.
• Add automatic query linting for high-risk operations such as broad joins, missing date filters, and ambiguous cohort definitions.
• Track every generated answer with provenance: question, intent, schema mapping, SQL, result table, reviewer status, and final response.
• Expand the UI so reviewers can approve, reject, or annotate intermediate steps without editing raw prompts.

Selected Sources From Original Report

The source report cited papers and technical references that informed the agentic reasoning, clinical NLP, feature engineering, and data-standard choices. The portfolio version keeps a curated source trail rather than reproducing the full bibliography.

Recruiter Signal

This project demonstrates the ability to design LLM systems around real operational constraints: privacy, auditability, structured data access, ambiguous user intent, and human oversight. It is most relevant for roles involving agentic AI, analytics engineering, healthcare data products, and responsible AI implementation.