Inspiration
Finding care should not require figuring out an entire healthcare system first.
At Virginia Tech, students navigate different services, eligibility rules, phone numbers, and scheduling portals—all while trying to find an appointment that fits their lives.
VT’s 2019 Mental Health Task Force report documented more than 25,000 Cook Counseling sessions in 2017–2018, intake waits of up to three weeks during fall semesters, and 34% dissatisfaction with long wait times in the cited survey responses. These figures are historical, and newer university reporting describes improvements. Still, they inspired our question:
How can we make existing care easier to find and coordinate?
We also wanted to help providers look ahead. Connecting someone to care addresses an immediate need; understanding regional respiratory trends could support preparation for the weeks ahead.
That became HokieCare: find care today, understand the health trends ahead.
What it does
HokieCare brings together two core experiences:
Care Assistant: Find and coordinate care
Students describe the support they need, their preferences, and their availability. HokieCare identifies relevant services using sourced information and presents matching appointment times.
Students can compare options, choose a time, explicitly confirm a reservation, and manage appointments from a private agenda. If a time is taken, they can join an exact-time waitlist and review an offer when it becomes available.
We used mock data to simulate real people creating and having appointments. This lets us demonstrate busy calendars, cancellations, scheduling conflicts, and waitlists without accessing private patient records. Saved reservations persist, but they do not create appointments with actual healthcare providers.
Health Intelligence: Understand what may come next
Health Intelligence turns 350 weeks of real New River district respiratory data into historical trends and an eight-week respiratory forecast.
Healthcare professionals can explore Emergency Department and Urgent Care data, inspect forecasts with 95% uncertainty intervals, compare predictions against simple baselines, and prepare an editable, sourced briefing.
The outlook describes regional respiratory activity—not individual illness or Virginia Tech appointment demand.
How we built it
We started with real data. Our Python ingestion pipeline loaded 28,700 public Virginia Department of Health records into Databricks, including 700 New River observations across two facility series. We preserved reporting dates, geography, and suppression flags rather than treating missing counts as zero.
We built the interface with React, TypeScript, Vite, Tailwind CSS, and Recharts, backed by Python and FastAPI, and deployed it using Docker and Railway.
Databricks supports three major parts of the application:
- Public-data analytics: Unity Catalog, Delta tables, and SQL views provide sourced service information and regional trends.
- AI matching: The hosted Qwen3 model interprets requests using service context. Backend rules validate its output and retrieve stored appointment choices.
- Persistent scheduling: Lakebase Postgres stores slots, reservations, proposals, and waitlists. Transactions prevent conflicting bookings, while shared availability updates keep names private.
We evaluate forecast accuracy using Mean Absolute Error:
$$ \mathrm{MAE}=\frac{1}{N}\sum_{i=1}^{N}|y_i-\hat{y}_i| $$
Lower MAE means smaller average prediction errors, measured in percentage points.
For forecasting, we used statsmodels SARIMA and compared its predictions against two baselines: last week’s value and the same week last year. The application serves a labeled precomputed forecast generated from real data. A notebook for Databricks publication and MLflow logging is prepared, with that execution still awaiting verification.
Challenges we faced
Making AI useful without giving it unchecked control
Interpreting a request is different from safely booking an appointment. We kept availability checks, ownership validation, conflict detection, and confirmation under deterministic backend control. The model helps identify relevant services; it cannot invent a valid appointment or directly save one.
Handling competing appointment requests
Two people might choose the same time, or several waitlisted users might respond after a cancellation. We implemented transactional checks so only one reservation succeeds, along with safe retries that do not create duplicates.
Evaluating forecasts honestly
A more complex model does not automatically produce a better forecast. Our seasonal baseline performed better for Emergency Department predictions, while SARIMA’s advantage for Urgent Care was small. We included those comparisons and uncertainty intervals directly in the experience.
Keeping the data’s meaning clear
Real public-health observations, sourced provider information, and simulated appointments serve different purposes. We kept those distinctions explicit throughout the project.
What we learned
We learned that a useful healthcare application needs more than an AI response. It needs trustworthy sources, clear service constraints, dependable database behavior, and a confirmation step that keeps the person in control.
We also learned that communicating uncertainty is part of building a forecast. Users should understand what a prediction measures, where it comes from, and whether it improves on a simpler approach.
Most importantly, we learned how to connect data ingestion, hosted AI inference, transactional storage, forecasting, and a deployed interface into one working product.
Accomplishments we’re proud of
We built both sides of HokieCare: an appointment-coordination prototype and a regional respiratory forecasting experience.
The application demonstrates persistent reservations, exact-time waitlists, conflict protection, sourced AI matching, and an eight-week outlook grounded in real data. We verified core workflows through application tests, browser checks, actual Databricks inference, and Lakebase transactions.
What’s next
Connecting HokieCare to actual campus healthcare centers is the next step toward widespread deployment.
That requires authorization and collaboration with Virginia Tech and participating providers, approved scheduling integrations, institutional identity, appropriate privacy controls, and provider-issued booking confirmations.
For Health Intelligence, we want to automate forecast refreshes, evaluate additional seasons, and work with healthcare professionals to understand how the outlook could support preparedness.
Our goal is to make care easier to navigate while giving providers a clearer view of the regional health conditions ahead.
Log in or sign up for Devpost to join the conversation.