MyIntake
A health profile patients carry, and any clinic can scan. No integration, no login, no IT approval. Built solo, concept to working app, in 14 days.
THE PROBLEM
Health records don't travel between systems, so intake often starts from scratch at every new provider.
THE OUTCOME
1st place, solo project. The full loop, from patient profile to QR code to clinic view, working live at the final pitch.
THE CONTEXT
14 days, zero to a working, tested app.
UW's iStartup Launch Sprint: judged on market validation, execution, and traction. I was the solo designer and builder: research, requirements, prototype, then an AI-assisted build.
RESULT
1st
place, solo project.
DISCOVERY
12
interviews across every care setting.
REQUIREMENTS
20
requirements, all interview-traced.
THE PROBLEM
Health information exists. It just doesn't travel.
Hospital systems don't talk to each other, so intake often starts from scratch at every new provider. Doctors can't treat safely without an accurate history, and patients can't recall it all from memory. It fails hardest for people who don't speak English fluently, don't have stable housing, or don't have one regular doctor.
27%
of hospital prescribing errors stem from incomplete medication histories at admission.
1.5M
people harmed by medication errors every year in the US.
$3.5B
in annual hospital costs from drug-related injuries alone.
Source: Tam et al., CMAJ 2005 · peer-reviewed systematic review
MARKET RESEARCH
The demand is real. The gap is structural.
Patient portals only work inside one hospital system. Switch providers, move, or need care elsewhere, and the information stays behind. Nothing lets patients carry it everywhere, without every provider signing on first.
65%
accessed health records online in 2024, up from 25% in 2014.
37–54%
actual portal adoption, despite near-universal availability.
0
portable patient-owned layers that work across providers without integration: the gap MyIntake fills.
Sources: ASTP/ONC Data Brief No.77, 2025 · Cao & Cao, Frontiers in Communication 2024 · peer-reviewed
The research base: 13 peer-reviewed studies, each mapping a finding to a product decision.
INFORMATION OVERLOAD Nijor et al. · J Patient Saf 2022
Overloading doctors with too much data raises error rates. Design response: the clinic view is a curated snapshot, not the full chart.
CARE FRAGMENTATION Kern et al. · JAMA Intern Med 2024
35% of Medicare patients saw 5+ physicians in 2019, and records don’t follow the patient. Design response: a portable profile the patient owns.
MEDICATION SAFETY AHRQ Medication Reconciliation · NCBI
The endorsed fix is a complete, portable, patient-maintained list, but it’s never been properly productized. We made it a core feature.
MEDICATION SAFETY Gleason et al. (MATCH) · J Gen Intern Med 2010
85% of admitted patients’ medication errors originate in history-taking. Design response: accurate patient-provided history, ready the moment a clinic scans.
PATIENT ACCESS Alomar et al. · JMIR 2024
Access to records correlates with engagement, but portals require patients to log in and pull the data. Design response: the QR code pushes the record to the clinic instead.
PATIENT ENGAGEMENT AJMC · M Health Fairview 2025
Only 54% of people who activated a hospital portal ever logged in again, over 13 years. Design response: no patient login required at the clinic.
IDEATION: JOBS TO BE DONE
Four actors, one shared failure: information that doesn't show up when it's needed.
What each person needed done: framed during ideation, then pressure-tested in the interviews.
PATIENTS
Get through a new-provider appointment without being asked questions I can’t answer, and have something to show that proves what I’m taking.
CAREGIVERS
Hold and present accurate information for someone who can’t self-advocate, without a formal power-of-attorney process every time.
CLINICAL STAFF
Start the encounter with accurate medication and allergy data already in hand, instead of reconstructing it verbally or by calling around.
PROVIDERS
Prescribe with confidence that the history is complete, even for a patient who just arrived from another system, state, or country.
USER RESEARCH
Every care setting told the same story: basic information doesn't show up when it's needed.
12 interviews: a hospital doctor, a pediatrician, a medical assistant, and a pharmacy technician, plus patients and caregivers.
"We spend too much time just getting basic information."
Medical assistant · primary care
"Most issues come from patients not having clear, accurate info."
Pharmacy tech · CVS
Key findings
Basic patient information is the highest-stakes gap. Providers can’t treat safely without it, and patients can’t recall the details from memory.
Intake is manually reconstructed at every visit. No persistent layer of patient information follows anyone from provider to provider.
The workaround that actually works is physical proof: written lists, photos, papers from hospitals. Memory stalls the encounter. Something tangible moves it.
Most patients don’t engage with existing portals: fragmented, hard to maintain, English-only in practice, and dependent on tech skills many patients don’t have.
The system fails hardest on people who don’t speak English fluently, don’t have stable housing, or don’t have one regular doctor. Interviewees described these as core users, not edge cases.
SCOPE & REQUIREMENTS
Cut twice: from sprawling wellness companion to one thin, complete loop.
The first concept covered health logs, symptom tracking, cost navigation, family history, and more: too much for 14 days. Two scoping passes later, the test was simple: one handshake judges could watch work, start to finish.
Wellness companion → ✕ ER angle → ✕ Schools angle → ✓ One loop: patient shares, clinic reads
PART 1 · PATIENT SIDE
A profile with only the fields clinics actually need: name, date of birth, insurance, allergies, current medications, reason for visit. Plus a QR code that doesn't expire, and an "anything changed?" prompt at return visits.
PART 2 · CLINIC SIDE: ZERO SETUP
Scan the QR and a read-only view opens on any device. No account, no install, no IT approval. A clinic can use it the moment a patient shows up with a code.
Features earned their slot by tracing to a breakdown someone actually described.
Findings mapped to opportunities, opportunities to features. Two features were cut for scope, then brought back after rechecking interview data. Three were cut for good: not bad ideas, just ideas no interview supported.
PATIENT HEALTH PROFILE ✓ IN SCOPE
The minimum information every new encounter needs: meds, doses, allergies, diagnoses, surgeries.
SHAREABLE SUMMARY VIEW ✓ IN SCOPE
A read-only version to show at intake, the pharmacy counter, or mid-encounter.
CAREGIVER / DELEGATE ACCESS ✓ IN SCOPE
The record exists independently of which person attends the appointment.
LOW-BARRIER DATA ENTRY ✓ IN SCOPE
Photo capture of pill bottles and documents as input: the workaround patients already use, made first-class.
CARE TEAM DIRECTORY ✓ IN SCOPE
Cut for scope, then brought back: interview data supported it more than the first pass suggested.
SYMPTOM & CONDITION LOG ✓ IN SCOPE
Cut, then brought back: a father who couldn’t say how long his child’s cough had lasted made the case.
APPOINTMENT REMINDERS ✕ CUT
No interviewee described scheduling as a failure point. The problem is what patients bring, not whether they attend.
EMERGENCY / CRISIS MODE ✕ CUT
Not surfaced in any interview as a primary breakdown. A genuinely different job from clinic workflow.
INSURANCE & BILLING ✕ CUT
Never mentioned as friction in the care encounter itself.
The feature map: four layers, tagged by what actually shipped.
PROFILE: THE HEALTH IDENTITY LAYER
Profile builder SHIPPED
Family profiles: one account, many people SHIPPED
FHIR / portal import ROADMAP
SHARING: THE PORTABILITY LAYER
Persistent QR code SHIPPED
Shareable link, no clinic login SHIPPED
Curated clinic view SHIPPED
UPDATES: THE CONTINUITY LAYER
Patient self-update, logged with timestamp SHIPPED
Post-visit push from clinic ROADMAP
FHIR auto-sync ROADMAP
PREVENTIVE: THE PROACTIVE LAYER
Care checklist: screenings & vaccines SHIPPED
Reminder cards ROADMAP
Shared care checklist for caregivers ROADMAP
20 requirements, every one traced back to an interview.
Six feature areas, 8 must-have (P0). Priority key: P0 must-have for the sprint · P1 important · P2 nice-to-have.
HEALTH PROFILE 4× P0 · 1× P1
Meds with active/inactive status, allergies, conditions, prescribed-vs-actual dose, photo input
SHAREABLE VIEW 4× P0
Read-only summary, QR + link share, pharmacy verification, provider-facing clinic view
CAREGIVER ACCESS 3× P1
Delegate authorization, delegated editing, patient-controlled revocable permissions
CARE TEAM DIRECTORY 2× P1 · 1× P2
Provider + specialist list, pharmacy and prescribers, caregiver visibility
SYMPTOM LOG 1× P1 · 1× P2
Onset + duration tracking, photo capture of symptoms
ACCESSIBILITY 2× P0 · 1× P2
Low-friction onboarding, language support, proxy-navigable UI (hand your phone to someone)
PRD-01 · P0 · PATIENT
"Store my current medications with names, dosages, and active/inactive status, so I can show a provider what I'm actually taking without relying on memory."
PRD-07 · P0 · PATIENT
"Share my profile via QR code or link, so I can hand it to a provider without requiring them to download anything or create an account."
PRD-20 · P0 · ELDERLY PATIENT
"Make the interface simple enough that a family member or provider could navigate it on my behalf if I hand them my phone."
DESIGN
The patient profile, QR code, and clinic view, all working together, live.
The journey: seeing a new provider (1 of 4 mapped journeys)
BEFORE VISIT SELF-UPDATE
Quick profile review
Patient checks the profile is current and updates anything that changed since last visit.
AT CHECK-IN QR / LINK
Share with provider
Sends the link by text, turns the phone to show the screen, or hands over the QR. Opens in any browser.
DURING VISIT CLINIC VIEW
Provider reads curated view
Allergies, meds, conditions, and reason for visit, surfaced in the order staff need them.
AFTER VISIT SELF-UPDATE
Patient updates profile
New diagnosis or prescription goes into the profile while it’s fresh, prompted by one question: “anything changed?”
NEXT VISIT NO RE-INTAKE
Profile is current
The next provider sees an up-to-date record immediately, without re-asking the same questions.
The QR handoff, live: patient side and what the clinic sees after scanning.
Multi-profile: one account, many people.
Sarah manages her own profile and her mother Rose's. Caregiver access was a P1 requirement traced straight to the interviews.
KEY DECISION · POSITIONING
Neither side shows up without the other already there. The fix: make one side free to join.
Patients need clinics to accept the profile, and clinics won't adopt a tool patients don't carry. Making the clinic side work with zero setup, just open a link, breaks the standoff.
AI-ASSISTED BUILD
The first project I went all-in on AI. Directing it mattered more than what it generated.
AI was involved in the whole process, not just the code: pressure-testing my research conclusions, compressing findings into a traceable set of requirements, and building the app with Claude Code and OpenCode, on React, Supabase, and Vercel. Every output was checked against the interviews and the requirements. The AI generated, I decided.
FIRST REAL AI WORKFLOW
My first project going all-in on agentic AI. The real learning was the scaffolding that makes it reliable: a review.md the agent checks before big changes, skill.md files for patterns worth repeating, and disciplined git push/pull so a new session picks up cleanly where the last one stopped.
RESEARCH PRESSURE-TEST
Used Claude to challenge my own research findings. It caught claims drifting past what interviews actually supported, before a flawed premise could reach the requirements doc.
INTERVIEWS TO REQUIREMENTS, FAST
AI accelerated mapping findings to jobs, journey breakdowns, and 20 traced requirements: days of documentation work compressed into hours.
BUILDING WITH AI
Claude Code and OpenCode on React, Supabase, and Vercel. Explicit instructions not to rewrite working files, and a defined what-NOT-to-build list, kept generation on scope.
DEMO-DRIVEN POLISH
The whole loop worked end to end. Polish time went where the live demo would linger: clinic view and care checklist. A seeded medication conflict tested that discrepancies surfaced clearly.
RESULTS
1st place, solo project. The full demo loop, working live.
✓ 1st place, solo project. Judged on market validation, execution, working prototype, and traction.
✓ Working app: the full loop, from patient profile to QR code to clinic view, ran live at the final pitch.
✓ 100% of interviewees said they’d use or try the product.
✓ Epic (hospital records) sandbox registered for testing. Import isn’t built yet; a mock version covered the demo.
WHAT I LEARNED
AI works best as a collaborator across the whole process. It caught overclaiming in my research before a flawed premise could reach the requirements doc.
Going all-in on AI changed how I scope. When build cost drops toward zero, deciding what NOT to build becomes the real bottleneck.
The skill on display is judgment: knowing when to redirect, what to constrain, and what not to build.