All work

Case study

Full-Stack AI Application

  • React
  • TypeScript
  • Vite
  • Vitest
  • Testing Library
  • Node.js
Collaboration pending verificationFeatured

Collaboration attribution pending repository history verification. Do not claim solo authorship. Solo authorship is not claimed.

Clinical Follow-Up Detector

A demonstration application that analyzes fictional clinical text notes and extracts explicit treatment and follow-up instructions into structured, reviewable actions.

View repository

Clinical note · evidence · review

Source note

Repeat CBC in seven days and schedule an oncology follow-up next month.

Fictional data

Extracted actions

Needs reviewFollow-up

Schedule oncology follow-up next month

Evidence: “schedule an oncology follow-up next month”

PendingLab

Repeat CBC in seven days

Conceptual preview of note-to-action review. Static fictional content only — not a live medical analysis interface.

Conceptual product preview for Clinical Follow-Up Detector

Problem

Clinical notes may bury explicit follow-up instructions inside unstructured prose, making treatment and follow-up tasks easy to miss during review.

Solution

The application surfaces those instructions as structured actions that a human can review, edit, confirm, reject, or mark complete—without treating model output as trusted truth.

Contribution

Keren’s contribution

Implemented a full-stack demonstration spanning React, Node, Python AI extraction, validation, and review workflows. Collaboration attribution remains pending verification.

  • Implemented note input, .txt upload validation, analyze flow, and review UI states
  • Designed Node as the application boundary for validation, workflow, and SQLite persistence
  • Isolated AI concerns in a Python FastAPI service with structured output validation
  • Treated LLM output as untrusted input with Zod validation and evidence checks

Architecture

  • React communicates only with the Node API
  • Browser never directly calls Python or OpenAI
  • Node owns validation, IDs, workflow rules, errors, and SQLite persistence
  • Python is an isolated AI service for prompts, model communication, and structured parsing
  • LLM output is treated as untrusted input and validated before persistence
  • Analyze writes note and actions atomically; invalid AI output creates no partial record
  • New actions begin pending; only confirmed actions can be completed; rejected actions cannot be completed

Clinical Follow-Up Detector architecture

  1. 1. React

    → Node API · HTTP API

    Note input, upload validation, action review UI, and reload flows. Talks only to the Node API.

  2. 2. Node API

    → Python AI service · AI service call

    → SQLite · Atomic write

    Application boundary: validation, IDs, workflow rules, errors, Zod checks, and SQLite persistence.

  3. 3. Python AI service

    → OpenAI · Model request

    Isolated AI service for prompts, model communication, structured parsing, and Pydantic validation.

  4. 4. OpenAI

    LLM extraction component only. Output is treated as untrusted input.

  5. 5. SQLite

    Atomic persistence of notes and actions owned by the Node API.

Key engineering decisions

  • Separate AI service from application API

    Python owns prompts and model communication; Node owns product workflow and persistence.

  • Validate AI output at the boundary

    Node validates AI-service responses with Zod; Python validates structured output with Pydantic.

  • Verify evidence against source text

    Evidence is checked against the submitted note, and uncertain output is flagged for human review.

Interactive demonstration

Deterministic local simulation — not a live product session.

Portfolio simulation

Static portfolio demonstration only — fictional data, no medical submission.

Loading clinical simulation

Preparing Note · actions · architecture. Case-study content stays readable while this loads.

Challenge

  • Untrusted model output

    Prompt-injection text is treated as untrusted note content; the LLM remains only an extraction component.

Limitation

Known limitations

  • Saved notes can be restored from the URL or manual note-ID entry, but the app does not automatically remember the most recently opened note when no noteId exists.
Technical details

Technology stack

Production frontend

  • TypeScript
  • Vite
  • Vitest
  • Testing Library

Backend and full-stack

  • React
  • Node.js
  • Express
  • Zod
  • better-sqlite3
  • SQLite
  • Python
  • FastAPI
  • Pydantic

AI engineering

  • OpenAI SDK

What the product covers

  • Structured review workflow

    Extracted actions support evidence display, needs-review state, confirm, reject, edit, and complete.

  • Trusted application boundary

    Provider credentials stay server-side. Prompts and credentials are not exposed to the browser.

  • Deterministic review rules

    Validation, workflow, persistence, and review rules remain deterministic even when the LLM is mocked in tests.

What this demonstrates

  • — Full-stack TypeScript and Python service boundaries
  • — Structured AI output with validation and human review
  • — Evidence-aware extraction workflows
  • — SQLite-backed persistence with atomic writes
  • — Testable AI integration using mocked LLM responses

Additional engineering decisions

  • Atomic analyze persistence

    Analyze writes note and actions together so invalid AI output cannot leave a partial record.

Additional challenges

  • Human-review workflow integrity

    Pending, confirmed, rejected, and completed states must remain enforceable regardless of model quality.

Additional limitations

Known limitations

  • The portfolio simulation uses fictional static data only, does not accept arbitrary medical input, and never sends OpenAI requests.