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.
Repeat CBC in seven days and schedule an oncology follow-up next month.
Schedule oncology follow-up next month
Repeat CBC in seven days
Interactive demonstration
Deterministic local simulation — not a live product session.
Static portfolio demonstration only — fictional data, no medical submission.
Preparing Note · actions · architecture. Case-study content stays readable while this loads.
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.
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.
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
Note input, upload validation, action review UI, and reload flows. Talks only to the Node API.
Application boundary: validation, IDs, workflow rules, errors, Zod checks, and SQLite persistence.
Isolated AI service for prompts, model communication, structured parsing, and Pydantic validation.
LLM extraction component only. Output is treated as untrusted input.
Atomic persistence of notes and actions owned by the Node API.
Technology stack
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.
Atomic analyze persistence
Analyze writes note and actions together so invalid AI output cannot leave a partial record.
Challenges
Untrusted model output
Prompt-injection text is treated as untrusted note content; the LLM remains only an extraction component.
Human-review workflow integrity
Pending, confirmed, rejected, and completed states must remain enforceable regardless of model quality.
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.
- The portfolio simulation uses fictional static data only, does not accept arbitrary medical input, and never sends OpenAI requests.
Validation and reliability
Deterministic application rules remain in force even when the LLM is mocked.