Build a Hospital Triage App with Gemini

Build an AI-powered hospital bed and emergency triage app in Google AI Studio.

Introduction

30 Second Summary

When you arrive at a hospital emergency room, every second counts. Doctors need to know which beds are free and which patients are most critical at a glance.

In this project, you will build ArogyaBed, a hospital bed management and AI triage app, entirely through natural language prompts in Google AI Studio. You describe what you want in plain English, and the AI generates and deploys the full application for you.

What You'll Build

You submit a patient's symptoms, and within seconds Gemini returns a severity level, assigns the patient to the right hospital bed, and updates a live dashboard for everyone to see.

By the end of this project, you'll have:

A patient intake form where you type in symptoms and see an ESI triage level (1-5) with clinical reasoning returned in seconds. Critical patients (ESI 1-2) automatically get assigned to ICU beds while stable patients route to General Ward.
A live bed dashboard color-coded by status (green for available, red for occupied, yellow for cleaning) that persists across browser refreshes through Cloud Firestore.
A shareable live URL deployed on Cloud Run so anyone can demo your app from their browser.
Secret Mission: Add Firebase Authentication for staff-only bed management and build a triage analytics dashboard showing ESI distribution across patients.

Are there any prerequisites?

You need a Google Account and some familiarity with Google AI Studio. Everything runs in the browser, so no local development tools are required.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

Set Up Google AI Studio Build Mode

To build ArogyaBed, you need a workspace that lets you focus on the healthcare logic instead of wrestling with framework setup and boilerplate code.

Google AI Studio's Build mode is that workspace. You describe your app in plain English, and an AI agent generates the entire full-stack codebase for you. In this step, you will sign in, enter Build mode, and generate the initial ArogyaBed dashboard with a single prompt.

In this step, get ready to:

Sign into Google AI Studio and switch to Build mode.
Generate the initial ArogyaBed app with a natural language prompt.
Verify the app works in the live preview.

Open Google AI Studio and enter Build mode

Build mode is Google AI Studio's vibe coding environment. You describe what you want in natural language, and the Antigravity Agent generates a complete React frontend and Node.js backend for you.

Open your browser and navigate to https://aistudio.google.com.
Sign in with your Google Account.
In the left-hand navigation panel, click Build to enter Build mode.

You should see a chat panel on the left where you type prompts and a live preview panel on the right-hand side where your app will appear.

What is Build mode?

Build mode is a full-stack app builder inside Google AI Studio. You type a description of what you want, and the Antigravity Agent generates all the code across multiple files.

The Gemini API key is auto-configured as a server-side secret. No manual setup is required to start using the Gemini API in your app.

Don't see the Build option?

Make sure you are signed in with your Google Account at aistudio.google.com. If the left-hand navigation panel is collapsed, look for a hamburger menu icon to expand it.

help me find Build mode in Google AI Studio

Generate the initial ArogyaBed app with your first prompt

The chat panel is where you describe the app you want. The Antigravity Agent reads your description and generates the full codebase in one pass.

Copy the following prompt and paste it into the chat input box in Build mode:

Build a hospital bed management dashboard called ArogyaBed with these features:

1. A color-coded bed grid showing 20 hospital beds:
   - 5 ICU beds and 15 General Ward beds
   - Each bed card shows its bed number, department, and status
   - Color code by status: Available (green), Occupied (red), Cleaning (yellow)
   - Pre-load sample data with some beds set to different statuses

2. A patient intake form with fields for:
   - Patient name
   - Age
   - Symptoms (text area)
   - Vitals (blood pressure, heart rate, temperature)
   - A Submit button

3. A patient queue section (empty for now, will be populated later)

Use a clean, modern hospital dashboard layout with the bed grid and patient form side by side.

What does this prompt ask for?

The prompt describes three parts of the ArogyaBed dashboard. The bed grid is the heart of the app: 20 beds split across ICU and General Ward, color-coded so you can see availability at a glance.

The patient intake form collects the information the AI will need later for triage. The patient queue section is a placeholder you will wire up in the next step when you add the Gemini triage engine.

Press Enter (or click the send button) to submit the prompt.
Wait for the Antigravity Agent to generate the application. This typically takes one to two minutes.

Watch the live preview panel on the right-hand side. You should see a working app start to appear with a bed grid and patient form.

Preview not loading?

If the preview is blank or spinning, give it another minute. The Antigravity Agent sometimes takes extra time for larger apps.

If the preview still does not load after two minutes, try refreshing the browser page. Your chat history and generated code are preserved.

my app preview isn't loading in Google AI Studio Build mode

Verify the generated app works in preview

Before you check the result, take a moment to predict what you expect to see. Based on the prompt you submitted, what should the dashboard look like?

Look at the live preview panel and confirm you see a bed grid with 20 bed cards showing different colors (green for Available, red for Occupied, yellow for Cleaning).
Check that each bed card displays a bed number, department (ICU or General Ward), and status.
Confirm the patient intake form is visible with fields for patient name, age, symptoms, and vitals.
Click on a few beds to see if they respond to interaction.

You should see a hospital dashboard with a color-coded bed grid on one side and a patient intake form on the other. The bed grid shows a mix of green, red, and yellow beds from the pre-loaded sample data.

Refine with the chat panel

If anything looks off, you can type a follow-up message in the chat panel to adjust it. For example, try "Make the bed grid cards larger" or "Add a field for patient age" if it is missing. The Antigravity Agent updates the app in place without starting over.

Your ArogyaBed dashboard is alive in the preview. Next up, you will plug in the Gemini API so the app can actually analyze patient symptoms and assign triage levels.

Build the AI Triage Engine with Gemini

Your ArogyaBed dashboard has a sharp-looking bed grid and a patient intake form ready to go. Right now, though, submitting a patient does nothing useful.

In this step, you will connect the intake form to Gemini so it can analyze patient symptoms and assign an ESI (Emergency Severity Index) triage level from 1 to 5. You will also build a patient queue that sorts cases by severity so the most critical patients surface first.

In this step, get ready to:

Prompt the Antigravity Agent to add Gemini-powered triage to the patient intake form.
Test the triage engine with critical and non-urgent sample patients.
Add a priority-sorted patient queue with color-coded severity badges.

Prompt AI Studio to integrate the Gemini API for triage

The patient intake form collects symptoms, age, and vitals, but has nowhere to send them. You need a server-side API route that passes this data to the Gemini API and returns a structured triage assessment.

In the chat panel on the left side of Google AI Studio, type the following prompt:

Add AI-powered triage to the patient intake form using the ESI (Emergency Severity Index) system. When a patient is submitted, send their name, age, symptoms, and vitals to the Gemini API through the server-side backend.

Gemini should analyze the case and return a JSON response with:
- esiLevel: a number from 1 (most critical) to 5 (least critical)
- severityLabel: one of Resuscitation, Emergency, Urgent, Less Urgent, or Non-Urgent
- reasoning: clinical reasoning explaining the assessment
- recommendedBedType: either ICU or General Ward

Display the triage results clearly on screen after submission, showing the ESI level, severity label, reasoning text, and recommended bed type.

What does this prompt do?

This prompt tells the Antigravity Agent to create a server-side API route that calls the Gemini API with patient data. The GEMINI_API_KEY is already auto-configured as a server-side secret, so all API calls happen on the backend. Your key is never exposed to the browser.

The ESI framework gives Gemini a structured way to reason about medical urgency. ESI Level 1 means immediate life-saving intervention is required. ESI Level 5 means the patient is stable and no resources are anticipated.

Wait for the Antigravity Agent to finish generating the updated code. This typically takes 30 to 60 seconds.
Watch the live preview panel on the right. It reloads automatically once the agent finishes.

Preview not updating?

If the live preview shows an error or a blank screen, the agent may still be processing. Give it another minute and check if the chat panel shows a completion message.

If the error persists, try a follow-up message in the chat panel: "Fix the error in the preview" and the agent will debug the generated code.

Still stuck? Help me fix the preview error in Google AI Studio Build mode.

Test the triage engine with sample patients

The triage engine is wired up, but you need to confirm Gemini is reasoning correctly about medical urgency. Two very different patient scenarios will tell you whether the AI can distinguish a life-threatening emergency from a routine visit.

In the live preview, fill in the patient intake form with a critical case.
Enter any patient name.
Set the age to 58.
For symptoms, type severe chest pain, shortness of breath, profuse sweating.
For vitals, enter values indicating low blood pressure, such as BP: 85/55, HR: 120, SpO2: 89%.
Click the submit button.

Gemini should return ESI Level 1 or 2 with a severity label of Resuscitation or Emergency. The reasoning text should reference the alarming vitals and chest pain symptoms, and the recommended bed type should be ICU.

Now submit a minor case to see the other end of the spectrum.
Enter a new patient name.
For symptoms, type sore throat, mild cough for 2 days.
Enter normal vitals, such as BP: 120/80, HR: 72, SpO2: 98%.
Click the submit button.

This time, Gemini should return ESI Level 4 or 5 with Less Urgent or Non-Urgent severity. The recommended bed type should be General Ward.

What is the ESI triage system?

The Emergency Severity Index is a 5-level triage algorithm used in emergency departments to prioritize patients by urgency. ESI 1 means immediate life-saving intervention is required. ESI 5 means the patient is stable and no resources are anticipated.

In this app, Gemini acts as a decision support tool. It analyzes symptoms and vitals to suggest an ESI level, but a real triage nurse would always make the final call.

Triage results not showing?

If the form submits but no triage results appear, the Gemini API call may be failing silently. Try a follow-up prompt in the chat panel: "Show any API errors in the console and display them on screen so I can debug."

If Gemini returns unexpected ESI levels (e.g. Level 5 for chest pain), send a refinement prompt: "Make sure the triage prompt to Gemini emphasizes that chest pain with abnormal vitals is a high-severity emergency."

Need more help? Help me debug the Gemini triage results in my ArogyaBed app.

Add the patient to a priority queue after triage

Triaged patients need somewhere to go. A priority queue lets hospital staff see all patients ranked by urgency, so the most critical cases get attention first.

In the chat panel, type the following prompt:

After triage, add the patient to a patient queue list sorted by ESI level (1 at the top, 5 at the bottom). Display each patient's name, ESI level with a color-coded badge (red for 1-2, orange for 3, green for 4-5), symptoms summary, and timestamp.

What does this prompt do?

This adds a visible patient queue to your dashboard. Each triaged patient gets a color-coded badge based on their ESI level so staff can spot critical cases at a glance.

Red badges (ESI 1-2) signal life-threatening emergencies. Orange badges (ESI 3) mark urgent cases. Green badges (ESI 4-5) indicate routine visits that can wait.

Wait for the Antigravity Agent to finish updating the code and the preview to reload.

Before you test, think about this: if you submit a patient with "severe chest pain, difficulty breathing, dizziness" and another with "minor headache," which one should appear at the top of the queue and why?

Submit a patient with symptoms severe chest pain, difficulty breathing, dizziness.
Submit another patient with symptoms minor headache.
Submit 1 to 2 more patients with varying symptoms to fill out the queue.
Check the patient queue to confirm it sorts patients by ESI level, with the most critical at the top.

The patient with severe chest pain should sit at the top of the queue with a red ESI 1 or 2 badge. The minor headache patient should be near the bottom with a green ESI 4 or 5 badge. Each entry should show the patient's name, color-coded badge, symptoms summary, and timestamp.

Queue not sorting correctly?

If patients appear in the order you submitted them instead of by ESI level, send a follow-up prompt: "Sort the patient queue by ESI level in ascending order so ESI 1 is always at the top."

If badges are missing or the wrong color, try: "Make sure the ESI badges are red for levels 1-2, orange for level 3, and green for levels 4-5."

Something else going wrong? Help me fix the patient queue in my ArogyaBed app.

Your triage engine is analyzing patients and the queue is ranking them by severity. Next up, you will push this data to its limits and discover what happens when the unexpected strikes.

Hit the Data Wall and Add Firestore Persistence

Your triage engine is analyzing patient symptoms, assigning ESI levels, and ranking the queue by severity. The AI side of ArogyaBed is fully functional.

All that patient and bed data is currently living in the Node.js server's memory. What happens when the server restarts or you refresh the browser? This step puts that question to the test.

In this step, get ready to:

Experience the data loss problem firsthand by refreshing your app.
Enable Cloud Firestore to give your app a persistent database.
Verify that patient records and bed statuses survive a page refresh.

Observe the data loss problem

Your app has patient records in the queue and beds with different statuses. Let's see how durable that data really is.

In the live preview, submit 2-3 patients through the triage form with different symptoms. Use a mix of critical and minor cases so you see entries appear in the patient queue.
Manually change a few bed statuses on the dashboard. Mark some beds as Occupied or Cleaning so they no longer show the default state.

You should see a queue with multiple patients and a bed grid with some beds in red or yellow. Take a mental snapshot of what your dashboard looks like right now.

Before you do anything else, predict: what do you think will happen to all this data when you refresh the browser page?

Refresh the browser page.

Every patient is gone. Every bed status has reset to its default. All the data you just entered has completely vanished.

Why did my data disappear?

Your app's data was stored in the Node.js server's memory. When the page refreshes, the Cloud Run container that runs your backend can restart. Cloud Run containers have ephemeral filesystems, meaning anything stored in memory or on disk vanishes on every restart or scale-to-zero event.

This is a fundamental limitation of in-memory data in containerized environments. To make ArogyaBed usable, you need a database that lives outside the container.

Enable Firestore through AI Studio

Cloud Firestore is a NoSQL document database that lives outside your container. Data stored in Firestore persists no matter how many times your Cloud Run container restarts.

In the chat panel on the left side of AI Studio, enter this prompt to add Firestore persistence:

Add Firebase Firestore to persist all data. Store beds in a 'beds' collection and patients in a 'patients' collection. Bed documents should have fields for bedId, department (ICU or General), status (Available, Occupied, Cleaning), and assignedPatientId. Patient documents should have fields for name, age, symptoms, vitals, esiLevel, severityLabel, reasoning, recommendedBedType, assignedBedId, and timestamp. Load data from Firestore on page load and update Firestore on every change.

What does this prompt do?

This prompt tells the Antigravity Agent to replace in-memory storage with Firestore. It defines two collections: beds (20 documents representing hospital beds) and patients (one document per triaged patient).

The agent generates client-side sync code (typically a src/lib/firebase.ts file), provisions the database, and writes security rules. Every change in the app now gets written to Firestore immediately.

The agent will show a Firebase configuration card in the chat. You need to pick a region before Firestore can be provisioned.

Click the Settings icon on the Firebase configuration card to pick a region.
Confirm to enable Firestore. The agent automatically provisions the database and updates your app's code.
Wait for the agent to finish updating the code. The live preview reloads automatically when it is done.

Why is everything pinned to one region?

On the Starter Tier, all resources are pinned to the single region you choose when your first service is provisioned. This keeps things simple and ensures your Cloud Run container and Firestore database are co-located for fast reads and writes.

Don't see the Firebase configuration card?

Make sure your prompt explicitly mentions Firebase Firestore. If the agent generated code without showing the configuration card, try sending a follow-up message: "Enable Firebase Firestore integration for this project."

help me enable Firebase Firestore in AI Studio Build mode

Verify data persists across refreshes

Time to put Firestore to the test with the exact same experiment that failed a few minutes ago.

In the live preview, submit 2-3 patients through the triage form. Confirm that they appear in the patient queue with ESI levels and color-coded badges.
Change a few bed statuses manually. Mark at least one bed as Occupied and one as Cleaning.

Now predict: will the data survive this time, or will you see the same blank slate as before?

Refresh the browser page.

Your patients are still in the queue. Your bed statuses are exactly as you left them. The data survived the refresh because it is now stored in Firestore, not in the container's memory.

Change one more bed status, then refresh the page again to double-confirm persistence.

Two collections, one source of truth

Your Firestore database now has a beds collection with 20 bed documents and a patients collection that grows every time you triage a new patient. The app loads from Firestore on page load and writes on every change, so the database is always the source of truth.

Data still disappears after refresh?

If patient records or bed statuses still reset on refresh, the Firestore integration may not have completed successfully. Send a follow-up prompt in the chat panel: "Verify that all patient and bed data is being saved to and loaded from Firestore. Data should persist across page refreshes."

Also check that the Firebase configuration card was confirmed. If the agent skipped the setup step, Firestore may not be provisioned yet.

help me debug Firestore persistence in my ArogyaBed app

Your data is safe. Patients, triage results, and bed statuses all survive restarts now. Next up, you'll connect the triage engine to automatic bed assignment so critical patients get placed in ICU beds without a nurse doing it manually.

Connect Triage to Automatic Bed Assignment

Your patient records and bed statuses now survive page refreshes thanks to Cloud Firestore. The data wall is behind you.

The triage engine scores patients and the dashboard shows beds, but they are completely disconnected. A nurse would have to manually match patients to beds by eyeballing both panels.

In this step, you will connect them so ESI 1-2 patients automatically land in ICU beds and ESI 3-5 patients go to General Ward beds. That is what turns two separate screens into a smart system.

In this step, get ready to:

Add automatic bed assignment that routes critical patients to ICU beds and stable patients to General Ward beds.
Test the full triage-to-assignment pipeline with patients of different severity levels.
Build a discharge mechanism that cycles beds through Cleaning back to Available.

Prompt the agent to add automatic bed assignment

Right now, submitting a patient through triage fills in their ESI level, but nothing happens on the bed side. You need the server-side triage endpoint to automatically find and claim the right bed after Gemini scores the patient.

In the chat panel on the left side of Google AI Studio, enter this prompt to add automatic bed assignment logic:

After a patient is triaged, automatically assign them to a bed. ESI Level 1-2 patients should be assigned to the first available ICU bed. ESI Level 3-5 patients should be assigned to the first available General Ward bed. If no beds are available in the preferred department, show a warning alert but still allow the triage to complete. When a bed is assigned, update its status to 'Occupied' in Firestore and store the assignedPatientId. Update the patient record with their assignedBedId.

What does this prompt do?

This prompt tells the Antigravity Agent to update the server-side triage endpoint so that after the Gemini API returns an ESI level, the backend automatically finds and claims a bed.

ESI 1-2 (critical) patients get the first available ICU bed.
ESI 3-5 (stable) patients get the first available General Ward bed.
Both the bed document and the patient document in Firestore are updated so the assignment persists.

Wait for the Antigravity Agent to finish updating the code. The live preview should reload automatically.
Check the live preview panel. The UI may look the same for now. The real change is in the backend logic, which you will test in the next substep.

Agent showing an error or not updating?

If the agent seems stuck or the preview does not reload, try clicking the preview refresh button in the top right of the preview panel.
If you see a red error banner in the preview, copy the error text and paste it into the chat panel. The agent can usually fix its own mistakes.

Ask for help: why isn't my AI Studio agent applying my prompt correctly?

Test the full triage-to-assignment flow

The backend now has bed assignment logic wired into the triage endpoint. Time to prove it works by submitting patients and watching beds change status on the dashboard.

In the live preview, open the patient intake form.
Submit a critical case: enter a patient name, set the age, and type symptoms like severe chest pain, shortness of breath, profuse sweating with vitals showing low blood pressure.
After Gemini returns an ESI Level 1 or 2, check the bed dashboard. One of the ICU beds should have turned red (Occupied).
Check the patient's record in the queue. It should now display the assigned bed number alongside the ESI badge.

You should see an ICU bed turn red on the dashboard and the patient's queue entry show which bed they were assigned to.

Now submit a minor case: enter a different patient with symptoms like sore throat, mild cough for 2 days and normal vitals.
Verify that Gemini returns ESI Level 4 or 5 and the patient is assigned to a General Ward bed, not an ICU bed.
Check the patient queue. Both patients should appear sorted by severity, each showing their assigned bed number.

Why does ESI level determine the bed type?

ESI Level 1 (Resuscitation) and Level 2 (Emergency) patients need immediate life-saving intervention or are at high risk of deterioration. ICU beds have the monitoring equipment and staffing ratios these patients require.

ESI Levels 3-5 cover stable patients who need fewer resources. Routing them to General Ward beds keeps ICU capacity free for the most critical arrivals.

Bed not turning red after triage?

Make sure you submitted the patient through the triage form, not just filled in the fields. The assignment only triggers after the form is submitted and Gemini returns a result.
If the patient gets triaged but no bed changes color, the agent may not have connected the assignment to the Firestore update. Go back to the chat panel and prompt: "When a bed is assigned after triage, update the bed's status to Occupied in Firestore immediately so the dashboard reflects the change."

Ask for help: my triage returns an ESI level but the bed dashboard does not update.

Add a discharge mechanism to free beds

Beds fill up, but right now there is no way to free them. A real hospital cycles patients out through discharge, and the bed goes through a cleaning phase before it is available again.

In the chat panel, enter this prompt to add the discharge flow:

Add a 'Discharge' button next to each patient in the queue. When clicked, it should set the patient's status to 'Discharged', change their assigned bed's status to 'Cleaning', and after 3 seconds automatically change the bed status to 'Available'. Remove discharged patients from the active queue.

What does the discharge flow do?

Clicking Discharge sets the patient's status to Discharged and removes them from the active queue.
The assigned bed flips to Cleaning (yellow) in Firestore immediately.
After 3 seconds, the bed automatically changes to Available (green), ready for the next patient.

Wait for the Antigravity Agent to finish updating the code.
In the live preview, find one of the patients you submitted earlier in the patient queue.
Click the Discharge button next to that patient.
Watch the bed dashboard. The patient's bed should turn yellow (Cleaning) immediately.
Wait about 3 seconds. The same bed should automatically turn green (Available).
Confirm the discharged patient has been removed from the active queue.

Discharge button missing or bed not cycling?

If you do not see a Discharge button in the patient queue, the agent may have placed it elsewhere. Try prompting: "Move the Discharge button so it appears next to each patient entry in the queue list."
If the bed turns yellow but never goes green, the 3-second timer may not be writing back to Firestore. Prompt: "After 3 seconds in Cleaning status, update the bed document in Firestore to Available so the dashboard reflects the change."

Ask for help: my discharge flow is not working as expected.

Verify the full cycle end to end

You have tested assignment and discharge separately. Now run the full cycle in one go and prove the data survives a page refresh.

Before you start, think about what you expect to happen. If you submit a critical patient, discharge them, and then refresh the page, will the bed be green or red? Will the discharged patient still appear in the queue?

Submit a new critical patient with symptoms like severe chest pain, difficulty breathing, dizziness and watch an ICU bed turn red (Occupied) on the dashboard.
Click Discharge on that patient. Watch the bed turn yellow (Cleaning), then green (Available) after a few seconds.
Refresh the browser page.
Confirm the bed is still green (Available) and the discharged patient is no longer in the active queue. All state persists in Firestore.

The full cycle works end to end. A patient comes in, Gemini triages them, the system assigns a bed, and discharge frees it back up. All of it persists across page refreshes.

Your app now manages the full patient lifecycle, from triage to bed assignment to discharge. Next up, you will deploy it to Cloud Run so anyone can access it from a live URL.

Deploy to Cloud Run and Get a Live URL

Your ArogyaBed app handles the full patient journey. From AI-powered triage to automatic bed assignment to discharge, every action persists in Firestore.

Right now, the app only exists inside your Google AI Studio session. In this step, you will deploy it to Cloud Run to get a permanent, shareable URL that anyone can visit.

In this step, get ready to:

Publish the ArogyaBed app to Cloud Run via the Starter Tier.
Test the deployed app end-to-end on the live URL.

Publish the app to Cloud Run

Google AI Studio has a built-in publish flow that packages your app and deploys it to Cloud Run in a few clicks. No Dockerfile, no CLI commands, no YAML configuration needed.

In Google AI Studio, click Publish.
Click Get Started.
Click Publish App.

Wait for the deployment to complete. This typically takes under a minute. When it finishes, a live .run.app URL appears on screen.

What happens when you click Publish?

AI Studio packages your React frontend and Node.js backend into a container and deploys it to Cloud Run on the Starter Tier. The GEMINI_API_KEY stays configured as a server-side secret, and your Firestore database remains connected.

The Starter Tier requires no credit card or billing account. Your Cloud Run service scales to zero when idle, so there is no cost while the app is not being used.

Starter Tier app slots

The Starter Tier allows up to two active web applications per Google Account. This deployment uses one of those slots.

Copy the .run.app URL displayed on screen.

Deployment not completing?

Make sure you clicked Publish App after Get Started. Stopping at Get Started does not trigger the deployment.
If you see an error mentioning resource limits, you may already have two apps deployed on the Starter Tier. You will need to redeploy over an existing app to free a slot.

Still stuck? Ask for help.

Test the live deployment

Your app is now running on Cloud Run instead of the AI Studio preview. Before you test it, what do you expect to see when you submit a critical patient on the live URL? Will the Gemini triage, bed assignment, and Firestore persistence all work the same way?

Open the .run.app URL in a new browser tab or an incognito window.
Verify the app loads with the bed dashboard and patient intake form.

The app should look identical to the AI Studio preview. The bed grid, patient form, and patient queue are all present because the same code is running inside the Cloud Run container.

Submit a patient with symptoms like "severe chest pain, difficulty breathing, dizziness" and set vitals showing low blood pressure.
Confirm that Gemini returns an ESI level (1 or 2) with clinical reasoning and the patient is assigned to an ICU bed.
Check that the assigned bed turned red (Occupied) on the bed dashboard.

The full pipeline works on the live deployment. Gemini analyzes symptoms, assigns an ESI level, and the system automatically routes the patient to an available bed.

Refresh the browser page and verify the patient record and bed status persist.
Share the URL with someone else and ask them to open it. Both of you should see the same bed statuses since you are reading from the same Firestore database.

Why does data persist across users and refreshes?

The deployed app connects to the same Firestore database you set up in the previous step. Every patient record and bed status update is written to Firestore, not stored in the container's memory.

This means any browser hitting the same URL reads from the same source of truth. It also means your data survives container restarts, which is exactly the problem you solved in the previous step.

App not loading on the live URL?

If the page shows an error or a blank screen, return to Google AI Studio and check that the deployment status shows as successful. You may need to click Publish App again.
If triage is not returning results, the Gemini API key may not have carried over to the deployment. In the AI Studio chat panel, ask the agent to verify the API key is configured in the server-side environment.
If data is not persisting, check that Firestore was properly enabled in a previous step. The Firebase configuration card should show an active database.

Need help debugging your deployment?

Secret mission

Add Staff Authentication and Triage Analytics

Right now, anyone with your live URL can discharge patients and change bed statuses. Your mission: add Firebase Authentication so only authorized hospital staff can manage beds, then build a triage analytics dashboard showing ESI distribution and bed occupancy metrics.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. The Starter Tier requires no credit card or billing account, so you cannot accidentally incur costs.

Resources you used:

Cloud Run service (ArogyaBed deployment). This uses 1 of your 2 Starter Tier app slots. Scales to zero when idle, so there is no cost while not in use.
Cloud Firestore database. Contains beds and patients collections with shared daily quotas (50,000 reads/day, 40,000 writes/day, 1 GiB storage). No cost on the Starter Tier.
Firebase Authentication. Google Sign-In configuration for staff access. Metered separately from Firestore. No cost on the Starter Tier.

Keep everything running

No action needed. Choose this if you are still actively building or iterating on ArogyaBed in Google AI Studio.

Your Cloud Run service scales to zero when idle, so there is no compute cost.
Firestore data (patient records and bed statuses) persists across sessions.
This deployment uses 1 of your 2 Starter Tier app slots.
To continue iterating, go back to AI Studio Build mode, make changes in the chat, and click Publish again to redeploy. The same .run.app URL is preserved.

Pause - I'll come back to this later

Cloud Run on the Starter Tier scales to zero automatically when idle. Your app is already paused when no one is using it, so no manual action is needed.

Your Firestore data persists and is available whenever you revisit the app.
The .run.app URL remains active and shareable.
This deployment continues to use 1 of your 2 Starter Tier app slots. Keep this in mind if you want to build a second app.

Delete - I don't want to use this again

Remove your deployed app to free the Starter Tier slot and clear project data.

To free the Starter Tier app slot, deploy a new app over the existing one in AI Studio. You cannot manually delete the Cloud Run service from the console on the Starter Tier.
Firestore data will persist until you manually clear the collections. Open the Firebase console at console.firebase.google.com, navigate to Firestore Database, select the beds collection, and delete all documents. Repeat for the patients collection.
Firebase Authentication is tied to the AI Studio project. It is replaced automatically when you deploy a new app over the existing one. No separate action is needed.

That's a Wrap!

Nice work! You just built and deployed ArogyaBed, a full-stack hospital bed management and AI triage app, entirely through natural language prompts in Google AI Studio.

You've learned how to:

Built an AI-powered triage engine using the Gemini API that analyzes patient symptoms and returns ESI severity levels (1-5) with clinical reasoning.
Solved the ephemeral container data loss problem by integrating Cloud Firestore for persistent patient and bed data that survives page refreshes and container restarts.
Connected AI triage output to automatic bed assignment logic that prioritizes critical patients for ICU beds and deployed the finished app to Cloud Run via the Starter Tier, getting a free, shareable .run.app URL with no credit card required.
Secret Mission: Added Firebase Authentication for staff-only bed management and built a triage analytics dashboard with ESI distribution charts.

Ready to quiz yourself?