SleepSync
Sleep Health Management Application
A five-person team project connecting patient-reported sleep data with FHIR-based clinical context, prediction, and AI-generated insights.
Frontend development · integration · testing · debugging
- Context
- Georgia Tech CS 6440 · five-person team
- Role
- Frontend development, integration, testing, and debugging
- Focus
- Sleep data, clinical context, health informatics
- Team stack
- React, FastAPI, FHIR R4, PostgreSQL
What we built
SleepSync was a five-person team project for CS 6440 at Georgia Tech. The starting point was a narrow gap: sleep data is usually viewed on its own, while medications and health conditions are what give it clinical context.
The team built a prototype that brought patient-reported sleep information together with relevant clinical context from FHIR, a sleep-quality prediction, and a generated sleep summary, in a single application.
It was a course prototype, not a clinical product. It ran on synthetic patient records, its clinical value was not validated, and it was never used with real patients.
Team architecture
React SPA
Frontend
FastAPI backend
Application and integration layer
FHIR R4 / HAPI FHIR
- Patient
- Condition
- MedicationRequest
PostgreSQL
- Sleep logs
- Session data
ML and AI services
- Sleep-quality prediction
- Sleep summary generation
The frontend never called the FHIR server directly. The backend handled clinical-data fetching, model inference, and summary generation, and the frontend reached it over the API.
My part of the system
I worked primarily on the frontend, building an early dashboard prototype with sleep-trend visualization, stat cards, medication information, and API-connected views.
- React SPA
- primary area of contribution
- API boundary
- integration work
- Backend services
- team-built; I worked across this boundary during testing
The frontend was a shared codebase and the whole system was built by the team. This marks where I worked, not exclusive ownership of the frontend.
I later worked on the frontend experience for the AI-generated sleep summary, and after my primary assigned work I contributed across other parts of the project through additional implementation, integration testing, and debugging.
From prototype to team frontend
The early dashboard prototype was a single file of roughly 464 lines. It contained the sleep-trend chart, stat cards, and medication panel, wired to API responses. Team feedback at the time described the chart, stat cards, and medication panel as looking solid.
As the frontend became more componentized, a teammate's componentized branch became the base for the team frontend, with pieces such as SleepTrendChart, MedicationSidebar, SleepLogTable, StatCard, and Dashboard. My chart and API work could then be merged into that structure.
Building the first version was only part of the work. The project also required adapting that work to a shared component structure and making the pieces work together.
AI sleep summary
- Frontend
- GET /api/insights/summary/{patient_id}
- Loading state
- response.summary
- Display
The team added an AI-generated sleep summary. I worked on the frontend experience for it: calling the summary endpoint for a patient, showing a loading state while the response was generated, and rendering the returned summary text in the dashboard.
My part was the interface around the generated output and the asynchronous behaviour that comes with it, not the generation itself. The summary was produced by a service behind the backend.
Testing and debugging
Once the main pieces existed, much of the remaining work was integration: checking whether data moved through the system as expected, tracing problems across the frontend and backend boundary, and fixing issues before the final handoff.
After completing my primary assigned work, I contributed to integration testing and debugging across the project rather than staying inside my initial scope.
Team system and reported results
These are properties of the team system, not of my individual work.
- FHIR R4 clinical context served from a public HAPI FHIR test server, using Patient, Condition, and MedicationRequest resources.
- Synthetic patient records generated with Synthea, roughly 200 of them, used instead of real patient data.
- A Random Forest model for sleep-quality prediction using 26 features on a 1 to 5 scale. The team's final presentation reported approximately 91% accuracy for this model.
- AI summary generation through an external model service, with the backend handling the request.
- A deployed prototype: React frontend on Vercel, FastAPI backend on Render, and a PostgreSQL database on Render.
- Source code lived in Georgia Tech GitHub Enterprise, with a mirror on github.com. Repository links are not published here.
Identified as future work, not built: SMART on FHIR launch context, wearable integration, medication and sleep correlation detection, and validation with real patients.
What I took from it
The project made the connection between interface work and health-data infrastructure concrete for me. A chart or a summary on the screen depended on data moving correctly through APIs, backend services, and clinical data structures.
It also made collaborative development more tangible. Building a feature was only part of the work; integrating, testing, and debugging it with the rest of the system mattered just as much.
I came out of it with a working understanding of how FHIR resources are used inside an application, and a clearer sense of how much integration work sits between a service and the person using the screen.
Sources and notes
This page is based on the project itself: the final team presentation, the project repository and records, contemporaneous team feedback on the early prototype, and task assignments.
- SleepSync final team presentation, Georgia Tech CS 6440, Spring 2026.
- SleepSync project repository and commit records (Georgia Tech GitHub Enterprise; github.com mirror, not published here).
- Early frontend prototype (single-file dashboard) and contemporaneous team feedback on it.
SleepSync was built by a five-person team. The system architecture, the FHIR integration, the synthetic dataset, and the machine-learning model are team work. My contribution is the frontend, integration, testing, and debugging work described above. Reported results are the team's, not mine.