Compliance for Children's Health Platforms: A FERPA, COPPA & HIPAA Checklist for Product Teams

By ForNex Health. 10+ years building compliant healthcare software for pediatric and school-connected platforms.

At ForNex Health, we spend most of our time thinking about HIPAA. It's the law our clients ask about first, the one baked into every architecture review, the one that shows up in nearly every RFP. And for most healthcare software, that instinct is right. HIPAA is the floor.

But every so often, we get a project where HIPAA isn't the floor. It's just one of three floors stacked on top of each other.

That happens the moment a child is involved.

The instant your platform touches a minor's data, you're not just a "covered entity" anymore. You're also, potentially, subject to COPPA, because a child under 13 is using your product. And if a school is anywhere in the picture (a district referral, a school-based therapy program, a classroom integration), FERPA enters the room too. Suddenly the compliance conversation your team has had a hundred times needs to happen three more times, with three different regulators, three different definitions of "consent," and three different answers to a question as simple as "how long can we keep this?"

We learned this the practical way, not from a legal brief, but from actually building for it. This checklist is the version of that lesson we wish we'd had on day one.

Why one child's data can trigger three different laws

Think about what a child is to different institutions at the same time.

• To a clinician, they're a patient → HIPAA
• To a school, they're a student → FERPA
• To your app, they're a user under 13 → COPPA

Same child, same data. Three separate legal identities, three separate rulebooks, all active simultaneously. A platform can be fully HIPAA-compliant and still be in violation the moment it ignores the other two.

This is exactly the situation we ran into on a recent K-12 platform build. Internally, we call it the Super School project. It started as what looked like a standard student-data platform. It didn't take long to realize that "standard" doesn't really exist once minors and health-adjacent data mix. More on what that taught us below.

The checklist

We built this the way we wish compliance guidance usually came: scannable, actionable, and organized by what you're actually deciding as a product team, not by which statute number governs it.

Age-gating & consent

Get consent before collection, not after, and know who is legally allowed to give it.

• Age screens should be neutral. A plain date-of-birth field, not a "Are you over 13?" checkbox that quietly invites a lie
• Verifiable parental consent is required before collecting any personal information from a child under 13
• If a school is the customer, consent may run through the school (the "school-official" exception), but only for the educational purpose the school authorized, never for marketing or ad use
• Document who's legally allowed to consent: a parent, a legal guardian, or in custody situations, whoever holds legal authority. Keep a record of it

Data minimization

Collect only what a feature needs, and treat every media type as regulated data.

• Collect only what a feature actually needs. No optional fields "for later"
• Treat voice recordings, photos, and video the same as names and emails. They're all regulated personal information the moment they're captured
• If you're extracting biometric data (like a voiceprint) from audio, that's its own protected category. Don't assume general audio consent covers it

Retention limits, by data type, not by default

There is no single retention number. Each data type follows a different rule.

• General account data: COPPA requires "reasonably necessary," written into policy. Not indefinite, not undefined
• Education records: FERPA sets no federal number. It's governed by the school's state records schedule
• Health/therapy records for minors: HIPAA doesn't set the clinical retention period either. State medical-record law does, and for minors it's typically age of majority plus several more years
• Compliance documentation (consent forms, agreements, audit logs): HIPAA does set a number here. Six years, fixed

Four data types, four different retention logics, sitting in the same database. That's the trap.

Security & access control

Encrypt everywhere, scope access tightly, and have a tested breach plan ready before you need it.

• Encrypt everywhere: in transit and at rest
• Role-based access. A clinician sees their assigned patients, not the whole roster
• Audit logging on every access to a record touching a minor's data
• A documented, tested breach response plan, with state notification deadlines already mapped. Not something you write for the first time during an actual incident

Vendor & subprocessor management

Every third-party tool inherits your compliance obligations, so vet it before it ships.

• Every SDK, analytics tool, or embedded widget inherits your compliance obligations. Regulators have pursued companies for third-party trackers they never personally vetted
• Every subprocessor (your cloud host, your transcription service, your email tool) needs a signed data-processing agreement with the relevant obligations flowing down to them
• Don't assume a vendor's general privacy policy covers children's or health data specifically. Check

Marketing & advertising

No behavioral ads on child-facing screens, and any promotional use of a child's data needs its own separate consent.

• No behavioral or targeted advertising on any child-facing surface. Full stop
• Using a child's data (or image) for marketing purposes requires its own separate, explicit consent. Your general sign-up consent doesn't cover it
• Even with consent, most major ad networks restrict targeting under-13 users regardless of what you've collected. This is rarely worth building toward anyway

Parental & guardian rights

Parents can review, correct, or delete their child's data, and you need a real process for all three.

• Parents can request to review, correct, or delete their child's data. Build a working process for this, even if it's not fully self-serve
• If consent is withdrawn, the data already collected generally needs to go too. Not just future collection halted
• Direct notice to parents before collection begins is required. A general privacy policy on your website isn't a substitute

What building Super School actually taught us

The checklist above reads clean. The real project didn't.

The thing that caught us off guard wasn't any single requirement. It was how differently the same kind of data had to be treated depending on which "hat" it was wearing at that moment. A recording of a child's voice during a school-referred therapy session wasn't one data point with one rule. It was health data (HIPAA), a student record (FERPA, because the referral came through the school), and a child's personal information (COPPA), all at once, all with different retention clocks, different consent requirements, and different people who were allowed to ask for it to be deleted.

We also learned that the biggest risk usually isn't the obvious stuff. Teams generally get consent and age-gating right because it's the first thing anyone checks. The risk hides in the boring infrastructure decisions: an analytics SDK added for a totally reasonable reason, configured with default settings that quietly collect a persistent identifier from a child. A retention policy that technically exists but was written once, in general terms, and never mapped against the four different data types actually living in the database.

The fix wasn't more legal review. It was building compliance into the same checklist a product team already runs through before shipping, so it stops being a special project and starts being a normal Tuesday.

Where this leaves your team

If your platform is HIPAA-compliant today and a school, a minor, or pediatric data is anywhere on your roadmap, the honest question to ask isn't "are we compliant." It's "compliant with which of the three."

That's usually the gap. Not bad intentions, just three rulebooks that were never designed to be read together, applied to a product roadmap that has to move fast anyway.

If you're building health software that touches minors and haven't mapped this yet, that's exactly the kind of audit we help teams run, before it becomes a support ticket, a parent complaint, or a regulator's letter. Reach out to ForNex Health and we'll walk through your specific data flows against this checklist together.