DEV Community: Inna Campo

When Doctors Are Too Tired to Think Slow: Building CLARA with Gemini 3.1 Pro

Inna Campo — Fri, 27 Feb 2026 15:25:28 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

Diagnostic error affects 12 million Americans annually. Behind that number are real encounters - patients who leave uncertain, physicians who move to the next room carrying doubt.

In women's health, this crisis is particularly acute: women are diagnosed on average 4 years later than men. A major factor driving this gap is Diagnostic Shadowing, a cognitive bias where a patient's physical symptoms are inadvertently misattributed to their psychiatric or chronic history.

It’s important to understand that this is rarely negligence. It is a breakdown of Dual Process Theory under pressure. High cognitive load forces burnt-out physicians to rely on System 1 (fast, heuristic thinking) just to keep up, bypassing System 2 (slow, analytical thinking). Necessary mental shortcuts can occasionally become unintended clinical blind spots.

To help solve this, I built CLARA (Clinical Logic Assessment & Reasoning Assistant).

CLARA is a multimodal AI agent powered by Gemini 3.1 Pro gemini-3.1-pro-preview. She acts as a Cognitive Forcing Strategy - an "External System 2" that supports physicians when cognitive bandwidth is limited.

Unlike standard AI medical scribes that merely record what is said, CLARA analyzes the logic of the encounter. Because Gemini 3.1 Pro is natively multimodal, CLARA can process consented consultation audio directly.

Designed as a post-encounter safety net, CLARA reviews recorded consultations prior to discharge, identifying high-risk reasoning patterns and generating standardized “Clinical Insights” in JSON format. In doing so, she transforms the subjective experience of “being dismissed” into objective, actionable data, protecting patients while supporting physicians under human constraints.

Demo

Check out the CLARA Github repository and live demo.
Test files can be downloaded here or try the Sample Cases.

What I Learned

Building CLARA taught me two massive lessons - one technical, and one deeply human.

1. The Human Element: Empathy in AI Design

Initially, I named the project the Clinical Logic Assessment & Reasoning Auditor. I programmed the AI to hunt for "dangerous biases" and output "Audit Flags." I quickly realized that this punitive framing would alienate the very people I was trying to help. Physicians are already under immense strain. I learned to completely rewrite my system prompts to shift the tone from evaluative to collaborative. CLARA is now an Assistant that looks for unintended clinical blind spots and offers gentle clinical nudges. Designing AI begins with understanding the psychology of the end user.

2. The Technical Element: Securing API Keys

While prototyping in Google AI Studio, I initially used the generated client-side JavaScript implementation. That approach quickly revealed a production concern: exposing the Gemini API key in the browser.

To harden the architecture, I introduced a dedicated Node.js/Express backend layer. The frontend now sends analysis requests to my server, which securely manages the API key via environment variables and handles all communication with Gemini. This shift transformed CLARA from a prototype into a securely deployable AI service.

Google Gemini Feedback

What Worked Well:

Gemini 3.1 Pro’s (and earlier Gemini 3 Pro's) native multimodality was transformative for this build. Not having to chain a separate Speech-to-Text model with an LLM significantly simplified the architecture. Furthermore, Gemini's ability to digest complex psychological concepts (like Anchoring Bias and Premature Closure) and apply them to raw conversational dialogue (while strictly adhering to my requested JSON output schema) was flawless.

Where I Ran Into Friction:

The primary friction point emerged around production security. Google AI Studio excels at rapid prototyping, and the generated client-side JavaScript is perfect for experimentation. However, moving toward deployment requires architectural adjustments, since client-side implementations expose API keys in the browser.

It would be powerful to see AI Studio offer a “full-stack” export option (for example, a minimal Node.js backend paired with a frontend scaffold) or include a more explicit production-readiness guide. That small addition could significantly reduce the learning curve for developers transitioning from prototype to secure deployment. This experience reinforced how important it is to think about security architecture as early as the prototyping phase when building AI systems.

Overall, building with Gemini 3.1 Pro allowed me to address a systemic healthcare issue with tools that did not exist just a few years ago. Next, I’m building SONA for the Gemini Live Agent Challenge, a voice-based simulator designed to strengthen women’s health communication. By allowing users to rehearse how they articulate menopause symptoms, SONA uses AI to help patients communicate with clarity and confidence before they ever step into the clinic.

P.S. Deep Dive: System Architecture & Technical Implementation

To ensure clinical data was handled securely and efficiently, I built CLARA using a two-tier client-server architecture, containerized via a multi-stage Docker build for deployment on Google Cloud Run.

Here is a breakdown of the technical stack and how the AI integration works under the hood.

1. The Stack

Frontend: React 19, TypeScript, Vite, Tailwind CSS, Recharts
Backend: Node.js 20, Express
AI SDK: @google/genai (v1.31.0)
Model: gemini-3.1-pro-preview

2. Client-Server Data Flow & Audio Processing

One of the core constraints of building with LLMs in the browser is API key security. To solve this, the React SPA never interacts with the Gemini API directly. Instead, I built a thin Express proxy server.

When a doctor uploads a consultation recording, the client-side process looks like this:

Validation: The React app enforces a 10MB file limit.
Encoding: The audio file is read via FileReader and converted into a base64 string directly in the browser using a custom utility function.
Transmission: The client POSTs the { type: 'audio', data, mimeType } payload to the Express server (/api/analyze).

To handle these large base64 strings, I had to configure the Express backend body parser with a 15MB limit (express.json({ limit: '15mb' })). The server then wraps this base64 data into an inlineData object and ships it to Gemini.

Note: Because Gemini 3.1 Pro is natively multimodal, we completely bypass the need for a separate Speech-to-Text (STT) transcribing step. The model ingests the audio directly.

Future Optimization: The Gemini File API
While the base64 inlineData approach works perfectly for short consultations, it creates memory overhead and strict payload constraints on the Express server. Moving forward, I plan to migrate this pipeline to use the Gemini File API. Instead of passing raw base64 strings in the JSON body, the backend will upload the raw audio directly to Google's infrastructure (using ai.files.upload), retrieve a fileUri, and pass that lightweight reference to the model. This will eliminate payload bottlenecks, reduce server memory pressure, and allow CLARA to seamlessly process much longer, high-fidelity consultation recordings.

3. Controlling the LLM: Structured Outputs & Temperature

Extracting consistent, usable data from LLMs can be notoriously brittle. To solve this, I leveraged Gemini's Structured Output capabilities.

I configured the ai.models.generateContent() call with a responseMimeType: 'application/json' and passed a strict responseSchema using the SDK's Type enum. This forces Gemini to map its analysis into an array of AuditFlag objects, matching this exact TypeScript interface:

interface AuditFlag {  
  timestamp: string;  
  bias_type: "Diagnostic Shadowing" | "Premature Closure" | "Anchoring Bias" | "Safe Practice";  
  risk_level: "High" | "Medium" | "Low" | "None";  
  dialogue_trigger: string;  
  clinical_reasoning: string;  
}

Because clinical analysis requires high determinism and zero hallucination, I also set the model's temperature to 0.2.

4. Advanced Prompt Engineering

The CLARA_SYSTEM_INSTRUCTION (an approx. 2,000-token system prompt) is the brain of the application. To prevent false positives, I engineered specific analysis rules:

Logic over Tone: The model is explicitly instructed that a provider can be highly empathetic but still exhibit a clinical blind spot, or be abrupt but logically thorough. It must focus only on reasoning pathways.
The "Testing Gap": The prompt trains the model to flag diagnoses made purely on assumptions rather than objective data (e.g., diagnosing a panic attack in a patient with tachycardia without ordering an EKG).
Constructive Framing: The model is commanded to output its clinical_reasoning as "gentle clinical nudges" rather than accusations, ensuring the resulting UI is supportive rather than punitive.

5. Frontend State Management

The UI is driven by a finite state machine managed by a single useState<AnalysisState> hook in the root App.tsx. Depending on the status (idle, uploading, processing, complete, or error), the component conditionally routes the user through the experience. Once the JSON payload returns from the server, Recharts processes the aggregated risk levels to render a donut chart, while a dynamic list of color-coded Audit Cards maps out the clinical insights.

SELENE: Why Women’s Healthcare AI Must Be Open, Local, and Privacy-First

Inna Campo — Wed, 25 Feb 2026 15:05:34 +0000

When it comes to women’s midlife health, particularly the neuroendocrine transition of menopause, there is a massive historical data gap. For decades, the standard of care has been reactive and fragmented. AI has the immense potential to close that gap by processing longitudinal symptom tracking, but the tech industry’s default response has created a new problem: the privacy deadlock.

We are building SELENE (Scientific Evidence-based Longitudinal Endocrine Neuropsychological Engine) to prove that high-utility medical AI does not require a data center. Currently in its alpha prototype phase, SELENE is a local-first medical intelligence engine. More than just a tool, it is an argument for why healthcare AI must be open source, open code, and fiercely protective of user privacy.

Here is why we built it, how the architecture works, and why we are calling on the open-source community to help us take it to the next level.

The Clinical Gap: The "Invisible" Transition

Menopause is not a singular medical event but a complex transition affecting the brain, cardiovascular health, and metabolic function over seven to ten years. Yet, clinical guidelines are often based on cross-sectional studies that fail to capture this fluctuating reality.

A woman might experience a constellation of symptoms, for example, disrupted sleep architecture, transient cognitive impairment ("brain fog"), and anxiety that don't align neatly with a 15-minute primary care visit. Because clinicians lack high-fidelity, structured data mapping symptom velocity over time, care often becomes guesswork. Women’s brain health deserves rigorous, longitudinal tracking that validates their lived experiences.

The Failure of Cloud-First AI

To solve this data deficit, the default tech solution is a cloud-centralized tracking app. But in today's digital landscape, the aggregation of intimate reproductive and neurocognitive health data on central servers poses an unacceptable risk. Asking women to trade their privacy to third-party data brokers for health insights is a non-starter.

When you decouple health intelligence from cloud surveillance, an interesting technical benefit emerges: you completely eliminate the attack vectors associated with transmitting sensitive data, and you don't even have to worry about securing cloud API keys or guarding against middle-man breaches because there are no external API calls. The data never leaves the hardware.

SELENE: A Neuro-Symbolic, Privacy-First Architecture

SELENE runs entirely on the user's device. We utilize the MedGemma 1.5 (4b) variant, optimized for edge deployment via Ollama, giving it a nuanced understanding of clinical terminology that general models lack.

The user experience centers on capturing structured data and qualitative notes, which are processed through a strictly local Retrieval Augmented Generation (RAG) pipeline:

Vector Database: We utilize ChromaDB running locally to manage semantic search for both a medical knowledge base and the user’s long-term history.
Retrieval & Synthesis: SELENE consults a locally stored, vector-embedded library of peer-reviewed research and endocrine protocols, synthesizing the user's logs with retrieved medical literature.
Knowledge Patches: To keep the AI current without exposing user data, we use a one-way update mechanism. The system pulls vector chunks of new research Server → Device. No user queries or chat history ever flow Device → Server.

Why Open Code is Non-Negotiable

Women's health has suffered for decades under opaque medical paradigms. AI cannot afford to replicate that with "black box" proprietary algorithms. We need open source and open code for three critical reasons:

Audibility of Safety Guardrails: LLMs are probabilistic, but patient safety must be deterministic. By making the code open, the community can verify our safety layers. For example, SELENE uses a deterministic math layer to analyze symptom velocity. If it detects a red flag (e.g., rapid deterioration in sleep combined with severe headaches), it forces the LLM to output a hard-coded referral warning.
Mitigating Bias: Proprietary models hide their training biases. Open weights like MedGemma allow researchers and clinicians to look under the hood and ensure the model isn't perpetuating gender-based medical biases.
Verifiable Trust: Open code is the ultimate proof that an application isn't quietly exfiltrating sensitive data in the background.

Call for Collaboration: Join the Alpha

SELENE is currently an alpha-first prototype. It proves the concept that we can build robust, locally-run, neuro-symbolic AI for midlife women's health. But to push this forward, it takes a village.

We are looking for open-source contributors:

ML Engineers: To help optimize quantized local models and improve our local RAG pipelines.
Frontend Developers: To refine our UI and ensure accessibility.
Clinical Researchers: Passionate about women's brain health, neurocognition, and endocrinology to help curate our Knowledge Patches.

We don't have to accept a future where healthcare AI is a black box that harvests our data. We can build it in the open, keep it local, and ensure it actually serves the people who need it most.

Check out the repository and live demo and let’s build AI that understands women’s health safely, openly, and securely.

Human-in-the-Loop, by Design: Evolving from Algorithms to Care-Centered AI

Inna Campo — Tue, 20 Jan 2026 23:37:02 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

Hello! I am Inna Campo, a Bioinformatics AI Scientist dedicated to building human-in-the-loop AI systems that prioritize clinical logic, safety, and gender equity in healthcare.

My career has been an evolution: from optimizing distributed algorithms for supercomputers during my PhD, to tracking viral outbreaks at the CDC with the GHOST platform, and scaling predictive modeling for millions of users at IBM. Today, as Principal Scientist at HARMONI Lab, I lead an independent initiative to develop multi-agent AI ecosystems and RAG pipelines centered on women's neuroendocrine health.

With this portfolio, I wanted to express that transition with a "bio-digital" aesthetic - something that feels calm, organic and alive, yet rigorously structured.

Portfolio

(Note: If the embed above doesn't load, you can view the live site here: innacampo.com)

How I Built It

This project is a high-performance, single-page application (SPA) portfolio that bridges the gap between scientific engineering (HPC) and human-centric Agentic AI. It features a "bio-digital" aesthetic built on a performance-first architecture. I primarily 'vibe-coded' this app using AI Studio and Antigravity. It was a truly magical experience; as someone whose expertise lies in bioinformatics and AI safety rather than web design, these tools bridged the gap, allowing me to build a modern, high-performance site from the ground up. I also used Gemini to navigate the rapidly evolving landscape of modern web development.

Here is the Technical Stack of the end product:

1. Core Architecture & Frontend

Framework: React 19
- Leverages the latest concurrent rendering features for smooth UI transitions.
Build Tool: Vite 6
- Optimized production builds with ultra-fast Hot Module Replacement (HMR).
Language: TypeScript 5.8
- End-to-end type safety for data constants, component props, and API interfaces.

2. Visual & Aesthetic System

"Washed Watercolor" Background:
- Engine: CSS Radial and Linear gradients layered for a diffused, organic look.
- Anti-Banding: A localized SVG fractalNoise filter (30% opacity, Soft Light blend) prevents color banding across diverse display types.
- Decorative Arc: A single, high-precision SVG Bézier curve that serves as a minimal visual anchor.
"Bio-Digital" DNA Loader:
- Transparent, full-screen loading sequence with a sharp, clinical aesthetic (no glows).
- CSS-driven helixMove animations for zero-jank page entry.
Styling: Tailwind CSS
- Integrated via runtime CDN for flexible, instant styling updates.
- Custom themes for Slate, Emerald, and Amber palettes.

3. Optimization & Performance

Particle Connections: The ParticleBackground (Neural Synapses) is hard-capped at 150 particles with $O(N^2)$ math optimizations and hardware acceleration hints (will-change: transform).
Lazy Loading: Implicit scrolling reveals and optimized asset paths ensure a fast initial payload.

4. Artificial Intelligence & Backend

AI Engine: Google GenAI SDK
Model: gemini-3-flash-preview
- Powering an context-aware "Inna AI" assistant with specialized personas for HPC and Public Health domains.
Backend: Express.js 5
- A secure proxy layer for the Gemini API ensures GEMINI_API_KEY protection.
- Serves compiled assets and handles client-side routing logic.

5. Deployment

Platform: Google Cloud Run
Infrastructure: Containerized via Docker; deployed as a stateless, auto-scaling service.
Contact Handling: Integrated with Formspree for reliable, serverless communication. pi/chat` endpoint for the AI chatbot.

What I'm Most Proud Of

I’m especially proud of the Custom AI Assistant integrated into the site. Far beyond a simple greeting bot, I engineered a specialized persona that can pivot between discussing high-performance computing (HPC) and complex public health domains, powered by a secure Express.js proxy to the Gemini API.

I am also proud of the development velocity achieved through AI Studio and Antigravity. By treating Gemini as a design and trend consultant, I was able to build a professional-grade SPA that honors my rigorous scientific background while meeting 2026's modern web standards, proving that "vibe-coding" is a legitimate and powerful tool for specialists to cross-pollinate their expertise into new domains.

P.S. If you're a fellow engineer, don't forget to check the console for a little surprise!

Roasting Turkey and Building Reasoning Engines

Inna Campo — Thu, 04 Dec 2025 17:43:20 +0000

This is a submission for the Google AI Agents Writing Challenge: Learning Reflections

Picture this: it’s Thanksgiving week. In the kitchen, I’m basting a turkey. At the kitchen table, I’m helping my 5-year-old draft a high-stakes letter to Santa. And on my laptop? I’m deploying a multi-agent AI system to Google Cloud’s Vertex AI.

If you saw me at the grocery store, you’d see a mom wrestling a 30-pound dog food bag and managing the holiday chaos. You probably wouldn't guess that I also hold a PhD in Computer Science and an MS in Bioinformatics. Moreover, I just finished the 5-Day AI Agents Intensive Course with Google and Kaggle, and I want to share how I deploy clinical-grade reasoning engines and why bringing a real-world perspective to tech is my biggest asset.

Before I get into the story, here is what I built:

Framework: Google Agent Development Kit (ADK)
Infrastructure: Google Cloud Vertex AI
Language: Python
Architecture: Multi-Agent System

I’ve learned something crucial: your best scientific insights often happen outside the lab. I am always expanding my dataset. While staying current with tech trends, entering motherhood gave me something academia alone couldn't: deep, ethnographic exposure to real-world stories. Suddenly embedded in a new community, I found myself listening to countless women navigate the complex, often overlooked realities of postpartum recovery and maternal healthcare.

I realized these conversations weren't just shared venting, they were field research. I took this course to get the advanced tooling I needed to solve the exact problems I was observing firsthand.

My capstone project, LUCIA (Language Understanding for Clinical Insight & Analysis), wasn't born out of frustration. It was born out of a specific scientific observation. Researching women's health (specifically postpartum, menopause and longevity), I noticed a pattern: women’s physiological symptoms are often complex and mimic mental health conditions like anxiety. Clinicians are brilliant, but they are time-poor. They often lack the tools to quickly parse these nuanced biological signals. I didn't want to blame the system but I wanted to enrich it. I wanted to build a "scientific second chair" for doctors, patients and researchers.

Initially, I thought I needed one giant model to do everything through comprehensive prompts. But the course taught me the power of separation of concerns. This was my "Aha!" moment. I architected LUCIA as a dual-engine system because a single agent can't effectively be both an empathetic listener and a cold, hard logician at the same time.

The system processes the patient's subjective narrative through four distinct stages to create a structured clinical asset.

Ingest & Map: The Digital Scribe
Agent 1 symptom_mapper: Acting as a scribe for overloaded clinicians, this agent ingests the user's narrative and translates emotional history into a structured Review of Systems (ROS).
Action: It updates the symptomMapping state in memory (e.g., mapping "brain fog" to neurological clusters), allowing the doctor to skip data entry and focus on diagnosis.

Audit: Clinical Decision Support
Agent 2 bias_analyzer : Acting as a non-judgmental "second opinion," this agent audits the narrative for cognitive traps like premature closure or attribute substitution.
Tool get_bias_implications : The agent queries the AXIOM Engine, a validated dictionary of bias implications, to ground its insights in external, controlled facts rather than LLM weights. The AXIOM Engine concept aims to repair the foundation of medical knowledge. While simulated for this capstone, the architectural vision is to bridge research gaps by scanning PubMed via MCP to flag systemic bias in literature and collect patient narratives to fill medical "Data Voids" with real-world evidence.
Action: It asynchronously updates the biasAwareness state, framing potential biases not as errors, but as diagnostic pivot points.

Advocacy: The Patient Prep Engine
Agent 3 advocacy_generator: Recognizing that a prepared patient is a partner, this agent transforms anxiety into a structured agenda.
Action: Based on the symptomMapping and biasAwareness states, it generates structuredAdvocacy - a list of differential diagnosis requests (e.g., "Given symptoms X and Y, should we check thyroid function?") - to focus the conversation on clinical investigation.

Structure: The Clinical Handoff
Agent 4 report_formatter: This agent compiles the final output into a professional Consultation Brief.
Action: It generates the final report using a standard medical note layout (Subjective -> Assessment -> Plan), ensuring the output is instantly scannable for the provider and positions the patient and doctor on the same side of the table.

I designed a pipeline that operates in a parallel layer where a symptom_mapper extracts patient sensations and a bias_analyzer audits for specific bias markers, followed by a sequential layer where an advocacy_generator and report_formatter synthesize these findings into a final Patient Advocacy & Consultation Aid.

I didn't just want LUCIA to chat, I wanted her to reason. To test this, I ran a series of diverse patient scenarios ranging from standard check-ups to complex, ambiguous presentations of hormonal imbalances. LUCIA successfully flagged potential biases in diagnostic logic, ensuring that physical symptoms weren't prematurely dismissed as psychosomatic. In test cases where a standard symptom checker might suggest "reduce stress," LUCIA was able to suggest specific biomarker panels to rule out physiological root causes.

Building LUCIA proved to me that the barrier to entry for impactful AI is lower than ever. The tools are intuitive enough that you don't need an enterprise team to build them.

I’m leaving this course with a renewed fire to pursue my passion for women's mental health research. We now have the tools to ensure science keeps up with the complexity of our biology.

And honestly, if I can build a clinical-grade reasoning engine while juggling my research, school runs, and writing letters to Santa, just imagine what you can build.