Building Something From All of It
Every chapter until now has proven one idea in isolation. Pick one real problem, sketch the data it would need and who could see it, and check it against everything this track has actually covered.
Read first: The Record That Replaced the Paper Chart, What Actually Has to Stay Private
Every chapter until now has proven one idea in isolation — a record, a device, a model, a regulation. Pick one real problem, sketch the data it would actually need and who could see it, and check the result against everything this track has covered, not just the part that inspired it.
Picking a real problem, not a vague one
“An app for better health” is not a problem, it is a mood. A real one names a specific person, a specific moment, and a specific gap: a patient managing a chronic condition who cannot tell whether a symptom is worth an appointment, a rural clinic with no specialist for a specific condition, a patient discharged from hospital with no easy way to flag that something feels wrong before it becomes an emergency. Pick something that specific before moving to the next step — everything after this depends on the problem being real enough to actually break against.
Run the same test on your own idea that the rest of this chapter runs on a worked example: a patient discharged after a cardiac event, sent home with a printed sheet of warning signs and no easy way to tell whether today's tiredness is normal recovery or something worth calling about. That is specific enough to have a real answer at every step below. “Help heart patients recover better” is not — it is the mood version of the same idea, and it could survive the checklist at the end of this chapter without ever being tested against anything.
Sketching the data it would need, and who could see it
Walk your idea through the same stages a real patient's data passes through, from Part 1 onward.
- 1
What data does it need to collect?
Name the specific fields — a symptom, a vital sign, a medication list — not just "health data" in general.
- 2
Where does that data already live, and in what format?
Does it already sit in an EHR? A wearable? Does it need to be entered by hand, and does that even matter for your idea?
- 3
Who is allowed to see each piece of it?
A patient, a specific clinician, a caregiver — name the roles the way Part 2's record viewer separated sections by role.
- 4
Where could an AI model help, and where should a human stay in charge?
Be specific about which decision, if any, gets assisted rather than automated.
- 5
Who gets left out if this only works with a smartphone and broadband?
Name the group Part 5's digital-divide chapter would flag, and what the fallback for them would be.
Seeing one idea answer all five questions
Before you answer those five questions for your own idea, see what a real answer actually looks like, worked through end to end for the discharged cardiac patient above.
Data: a short daily symptom check — breathlessness, swelling, weight — plus whatever a home blood-pressure cuff already reports. Where it lives: the blood pressure and weight come from a cuff and a scale the patient already owns at home. Owning the device is not what decides how far to trust it — the specific model's validation, clearance and intended use do. A validated home cuff used as directed can give readings a clinician acts on; an unvalidated one only gives a trend to watch. So the app records which device each reading came from, and the care team decides which ones count. The symptom answers are typed in by hand. Who sees it: the patient sees their own trend; a nurse on the discharging team sees flagged entries only, not the full daily log; nobody else does without the patient's consent. AI and the human: a model flags an entry as worth a nurse's attention; it never contacts emergency services or changes medication on its own — a nurse decides what happens next, every time. Who gets left out: a patient without a smartphone or reliable data plan, handled here with a daily automated phone call covering the same three questions, read out loud and answered on the keypad instead of tapped in.
Notice that every answer above is a specific fact, not a description of how good the idea sounds. That's what makes it checkable against the list below.
The checklist any idea here should survive
Run your sketch against the same questions this entire track has been asking of real systems, one part at a time.
Most ideas fail this checklist quietly, not with an obvious dealbreaker. The most common failure isn't a legal one — it's the last item: an idea that sounds low-risk right up until someone asks what happens the one time the model is wrong, and nobody in the room has an actual answer.
Before calling this idea finished
- →The problem names a specific person and a specific moment, not a general mood about health.
- →You can say which fields count as Protected Health Information, and which don't, under Part 2's HIPAA boundary.
- →You've named who sees which section of the data, not just that "the data is secure."
- →Any AI component has a named human reviewer in the loop, not an unsupervised verdict.
- →You've named a real fallback for someone without a smartphone or reliable broadband.
- →A bug in this specific idea would cost an inconvenience, not something unrecoverable — and if it's the latter, you've named what would actually have to be validated first.
What this track was actually teaching you to notice
Twenty-four chapters ago, this track opened with a claim: health tech is not six separate topics, it is one connected system, and every part of it changes shape the moment it touches an actual patient. The exercise you just ran is the proof of that claim, not a summary of it. You didn't just sketch an app — you touched every part this track walked through, in order, on one idea.
Part 1 gave you the reason the stakes are different here at all. Part 2 gave you the record, and the boundary around what has to stay private inside it. Part 3 gave you the gap between a wearable's estimate and a medical-grade measurement, which is exactly what decided whether your idea's data needed a nurse in the loop at all. Part 4 gave you the reason an AI component in your sketch needs a named human reviewer, not an unsupervised verdict. Part 5 gave you the patient who gets left out if an idea assumes a smartphone and a broadband connection everyone doesn't actually have. This part gave you the ransomware target your idea would become the moment it holds real patient data, and the regulator who decides whether it is even allowed to launch.
Key takeaways
- A real health tech idea names a specific person and a specific moment — not a general mood about improving health.
- Sketching the data pipeline — what's collected, where it lives, who can see it — surfaces problems no amount of enthusiasm for the idea would.
- Every AI component in a serious idea needs a named human reviewer, the same pattern held across every part of this track.
- An idea that only works with a smartphone and broadband has already excluded someone — naming who, and their fallback, is part of finishing the idea, not a later add-on.
- The question underneath all twenty-four chapters was never really six separate topics — it was always: does this help the patient, who can see it, and who answers for it when it's wrong.
Before you move on
Quick check
Answer these to unlock the next chapter: 3 of 4 to pass. You can retake it anytime.
Make a free account to read on
Every chapter is free — an account lets your course progress follow you from your laptop to your phone. No payment, no trial.