Project details

Each team of 3–4 builds a working Personal Health Assistant over the term: it pulls in real health data, stores and retrieves it, reasons over it through an LLM/RAG/agent component, and faces its user through an interface a non-technical person could actually use — with safety, privacy, and evaluation designed in rather than bolted on.

The project has three deliverables, and your project grade accumulates across them:

• Part 1 — Project idea one-pager (Week 4 · submitted Oct 2)
• Part 2 — Proposal presentation (Week 9 · Nov 6) · 15%
• Part 3 — Final demo (Week 14 · Dec 11) · 15% implementation + 15% demo + 15% writeup

Between the parts, the weekly labs carry the project forward — a project-direction discussion in Week 7, the Week 8 design studio that produces your proposal artifacts, and an integration checkpoint with a mock demo in Week 13 — so no part starts from a blank page.

Part 1 was completed with the one-page project idea pitch submitted on Friday, Oct 2.

The pitch outlined your team, target user and question, and proposed data sources. It is the starting point for the Week 9 proposal.

The proposal is where your project stops being an idea. By proposal day your team should know what your assistant does and for whom, and be actively working out how. This part is worth 15% of the course grade.

Bring something concrete

A slide of bullet points is not enough to present. Every team shows at least one tangible design artifact:

• a rough prototype, however small,
• a hand-drawn interface,
• a system or architecture sketch,
• or another concrete design artifact: a storyboard, an annotated user flow, a wireframe.

Reviewers can only give feedback as specific as what you show them — a team that presents a sketched screen hears “that confidence label will be misread”; a team that presents a concept hears “sounds interesting.” You will leave the Week 8 design studio with a storyboard, a core user flow, and a low-fidelity prototype: bring them, updated with everything you have decided since. And present live questions, not settled answers — feedback is most useful on the calls you have not yet made.

The presentation

Each team presents for 5 minutes, followed by 3 minutes of structured peer feedback; presentation order is announced in advance.

1. Problem statement and target user (1 min)
2. Data sources and access plan (1 min)
3. Technical architecture and interface concept (1.5 min)
4. Evaluation plan and timeline (1 min)

Show your artifact when you reach architecture and interface, and end with the one or two questions you most want feedback on. Anything interactive goes into the slides as screenshots or a short recording — you will not debug a live demo in a 5-minute slot. During the feedback round, listen and take notes rather than defending; instructors and TAs use the same protocol and hand you written cards.

The written draft is the Week 9 lab notebook — the five-part structure taught in class (problem, data plan, technical approach, evaluation, timeline & risks), finalized with the feedback from your presentation.

Have your slides ready by class time on Friday, Nov 6; submit the written draft by Wednesday, Nov 11, 11:59 PM ET.

The term ends with a poster-and-demo showcase: each team gives a one-minute lightning pitch, then the room breaks into rotating poster and demo stations. We plan to invite guests from industry, academia, and health AI practice. You will have rehearsed all of it at the Week 13 integration checkpoint and mock demo.

The lightning pitch has one goal: make people walk to your station. One minute covers the problem, the user, and the single most compelling thing your assistant does. Rehearse it out loud — a minute is shorter than it reads.

The demo is where a health AI system earns or loses trust, so demo honestly: show what the system actually does, label what is real data versus mocked, and claim no clinical authority the system does not have. Live demos fail at showcases; a team with a recorded fallback loses thirty seconds, a team without one loses the demo.

Checklist:

• A working system behind the demo (implementation, 15%)
• A live demo, with a recorded fallback (demo, 15%)
• A poster or visual summary, including your architecture diagram
• A short technical writeup (15%): what you built and how it works, your safety and privacy stance, what you measured against the criteria from your proposal, what you learned and would build next — plus who did what, and each member’s individual reflection (what I tried, what failed, what I learned, how I used AI). Due Wednesday, Dec 16, 11:59 PM ET (tentative), so you can write about what happened at the showcase.

The demo and the implementation behind it are graded separately: a slick walkthrough over hardcoded data will not carry a missing system, and a rough-edged demo of a genuinely working pipeline scores better than it feels.

Across all three parts, the same judgment applies.

We are looking for:

• A system that runs end-to-end on real or realistic health data
• Answers grounded in that data, with the source visible to the user
• Honest uncertainty: an assistant that knows when to say “I don’t know” and when to escalate to a human
• An interface a non-technical person could actually use
• Safety and privacy treated as design constraints, not disclaimers

We would also love to see:

• A novel interaction, retrieval, or agent design
• Evaluation with real users (classmates count)
• Graceful degradation when a model, API, or data source fails

Make sure you do not have:

• A happy-path demo with no fallback
• Overclaiming: diagnosis language or clinical authority the system does not have
• Unsafe outputs in scenarios where refusal or escalation was the right call
• A polished interface over hardcoded data
• A writeup that inflates results the demo cannot back up