• 

• 

• 

• 

Project Story: Engineering CareFlow

1. About the Project

CareFlow is a serverless, single-page Hospital Management System (HMS) designed to demonstrate the potential of lightweight frontend architectures in healthcare environments [2]. The application operates completely client-side, running from a single, portable HTML file with zero server-side dependencies [2]. Despite its serverless footprint, CareFlow features an interactive operational dashboard, a live-searchable patient registry, and two specialized AI-driven workflows powered by direct, browser-to-LLM integrations [2]:

• AI Triage & Admissions: Evaluates patient symptom descriptions using natural language, classifies emergency priority levels, isolates potential clinical risks, and recommends target departments.
• AI Discharge Letter Summarizer: Translates complex, highly abbreviated clinical shorthand notes into compassionate, readable, and structured discharge instructions for patients.

---

2. Inspiration

During surges in public health needs, such as seasonal epidemics, regional disasters, or humanitarian emergencies, setting up field clinics or temporary wards is critical. However, configuring full-stack enterprise hospital management systems with databases, servers, and networks in these settings is slow and difficult.

This inspired the development of a fully operational, zero-configuration clinical dashboard [2]. By loading all business logic, design templates, and operational states into a single browser-rendered document, CareFlow can be deployed instantly on any device with an internet connection [2]. Integrating the Gemini API lets the system handle complex clinical reasoning and translation tasks on the client side, removing the need for a dedicated backend server [1, 2].

---

3. How We Built It

CareFlow was developed using a clean, vanilla architecture designed for reliable rendering and portable deployment:

• User Interface: Styled with the Tailwind CSS CDN, utilizing slate grays, clean whites, and medical blues to create a focused, low-cognitive-load clinical dashboard. FontAwesome was integrated for immediate visual context across navigation and data fields.
• State Management: Implemented with a single, namespace-isolated JavaScript object (appState) that maintains the active patient records, state of current triage parameters, and local key authorization.
• Network Protocols: Designed to communicate asynchronously with Google's Generative Language API via standard browser fetch() requests, bypassing the need for Node.js-based SDKs [1, 2].

The Mathematical Modeling Behind the App

To model the triage evaluation conceptually, the prioritization decision-making algorithm evaluated by the AI can be represented mathematically. Let $\mathbf{x} \in \mathbb{R}^n$ be the vector of patient vitals and symptomatic indicators (such as pain localized to the chest, high blood pressure, and respiratory indicators).

The priority scoring index $I_p \in {1, 2, 3, 4, 5}$ can be modeled using a normalized logistic evaluation function over weighted clinical parameters:

$$I_p(\mathbf{x}) = \text{round}\left( \frac{4}{1 + e^{-\sum_{i=1}^{n} w_i x_i}} + 1 \right)$$

where:

• $x_i \in [0, 1]$ represents the scaled severity of clinical symptom $i$.
• $w_i \in \mathbb{R}$ represents the clinical risk weight assigned to that symptom (e.g., higher weights for cardiovascular symptoms).
• The output is rounded to the nearest integer to yield a standard scale from 1 (non-urgent) to 5 (immediate resuscitation).

---

4. Challenges Faced & Solutions

Challenge 1: Regional API Restraints & "Model Not Found" (404) Errors

When calling standard models like gemini-1.5-flash directly from the browser, the Generative Language API often throws 404 Not Found or 403 Forbidden errors. This is typically due to regional API restrictions (such as EEA privacy boundaries), outdated billing tiers, or keys that are restricted from legacy models.

Solution: Multi-Endpoint & Multi-Model Sequential Fallback

We resolved this by designing an automated, sequential fallback network in our fetch engine. If a connection fails, the engine retries the request across different API versions and models, including the stable /v1 and /v1beta routes, and a secondary fallback path via the /v1beta/openai/ compatibility gateway.

We also updated the default model selection to target the modern Gemini 3.5 Flash (gemini-3.5-flash) and Gemini 3.1 Flash Lite (gemini-3.1-flash-lite) models.

This multi-path fallback system significantly improves reliability. The overall system availability $A_{sys}$ across $k$ serial retry routes can be expressed as:

$$A_{sys} = 1 - \prod_{j=1}^{k} (1 - a_j)$$

where $a_j \in [0, 1]$ represents the individual availability rate of attempt $j$. By combining four models across both native REST and OpenAI-compatible paths ($k = 8$), the system is highly likely to find a working configuration for any valid key.

Challenge 2: Client-Side Code Mismatches & Runtime Freezes

In single-page applications, a single unhandled exception or missing element during DOM rendering can halt the entire script thread, leaving navigation buttons and form handlers unresponsive.

Solution: Defensive Namespace Protection

To address this, we decoupled the DOM interaction using a helper object called DOM to safely wrap all element lookups and modifications. We also mapped all critical event-handling functions (such as switchTab, runTriage, and generateDischargeLetter) directly to the global window object. This ensures that inline onclick event handlers can always access the scripts, even if other parts of the script experience minor issues.

---

5. What We Learned

Building CareFlow highlighted the balance between serverless portability and architectural resilience [2]. Removing backend servers simplifies deployment but places the responsibility of reliability, error handling, and API integration on the client side [2].

We also learned that public AI APIs can vary in availability based on geographical regions, model deprecations, and endpoint versions. When developing serverless tools, building fallback paths directly into the client-side code is essential for ensuring a stable and reliable user experience [2].

in summery: It does three key things:

1. Tracks Patients: Maintains a searchable registry of admitted, observation, and discharged patients.
2. Prioritizes Symptoms (AI Triage): Evaluates raw symptoms to assign an emergency score (1–5) and suggests the correct department.
3. Writes Recovery Letters (AI Discharge): Translates shorthand doctor notes into plain-language discharge letters for patients. By running directly in the browser, it requires no backend server setup.

Built With

• html