HIPAA-compliant behavioral decision-support platforms for children’s hospitals

Any behavioral-health platform touching a children’s hospital will carry the “HIPAA-compliant” label somewhere on its marketing page. The label, on its own, is not enough. HIPAA compliance is a specific, auditable posture defined by the Security Rule and the Privacy Rule, and it decomposes into a small number of controls a privacy officer can evaluate on a single call with a vendor.

This article walks through those controls, explains why pediatric settings add a layer of complexity, names the infrastructure-level pitfalls that quietly break compliance, and ends with a one-page procurement checklist the hospital privacy office can use directly.

The five HIPAA controls every behavioral platform must demonstrate

1. Administrative safeguards — 45 CFR 164.308

Administrative safeguards are the governance layer: security management processes, workforce training, information access management, contingency planning, and periodic risk analysis.[1] The question for a privacy officer is not whether the vendor has a policy document — they will — but whether the vendor can show you the outputs: the most recent risk analysis, the workforce training log, and the contingency-plan test results.

2. Physical safeguards — 45 CFR 164.310

Physical safeguards cover facility access controls, workstation and device security, and media disposal.[2] For a cloud-native platform, these mostly flow through the cloud provider’s controls. The right diligence question is: which cloud services are you using, are those services specifically BAA-covered by the provider, and will you share the subprocessor list?

3. Technical safeguards — 45 CFR 164.312

Technical safeguards include access control, audit controls, integrity controls, person-or-entity authentication, and transmission security. The specific subsection the pediatric behavioral-health industry tends to underbuild is 45 CFR 164.312(a)(2)(iii) — automatic logoff.[3] A platform that keeps a clinician logged in indefinitely between interactions is not compliant, regardless of what the marketing page says. A 15-minute auto-logoff is the conservative default.

4. Audit controls — 45 CFR 164.312(b)

Audit controls require the recording and examination of activity in information systems that contain or use ePHI. In practical terms: can the platform show who read, created, modified, or exported each record, with timestamps, and can it retain those logs for the period the hospital’s policy requires? Ask to see a sample audit-log export before the pilot, not after.

5. BAA and subprocessor terms — 45 CFR 164.314

A Business Associate Agreement is not optional, and neither is the chain of downstream BAAs with the vendor’s subprocessors.[4] If the platform stores PHI in any third-party service, each of those services must be a HIPAA-eligible product from a BAA-covered provider, and the vendor must carry a back-to-back BAA. The two failure modes to watch for: analytics tools (Google Analytics, Mixpanel, and similar) placed on PHI-bearing pages without BAA coverage; and CDN or edge services sitting in the request path for PHI traffic without BAA coverage.

Why pediatric settings add complications

Pediatric behavioral health sits at the intersection of three overlapping regulatory surfaces, and the platform has to handle all three.

Parental authorization and access

HIPAA treats a parent as a personal representative of the minor child for most purposes, which means the parent can authorize uses and disclosures and can typically access the minor’s protected health information. The exceptions are narrow but consequential — state laws that permit a minor to consent to a specific category of care (behavioral health, reproductive health, substance use) may restrict parental access to records of that care. The platform has to be able to express, record, and enforce those exceptions, not just a generic “parent can see everything” setting.[5]

Mature-minor considerations

Mature-minor doctrine is a state-law matter layered on top of HIPAA. In states where a mature minor can consent to their own behavioral care, the record generated in the course of that care may be subject to the minor’s consent rather than the parent’s. A platform without a per-record consent model cannot represent this correctly.

HIPAA and FERPA jurisdictional split

When a behavioral platform spans a clinical setting and an educational setting — which is the entire point of NeuroPath’s school-side flow — the record’s status can change between HIPAA-protected PHI and FERPA-protected educational record depending on where it lives and who generated it. The US Department of Education and HHS have issued joint guidance on this interaction.[6] The platform has to represent that split clearly and must not leak a HIPAA-scoped record into a FERPA-scoped surface, or vice versa, without explicit consent.

The infrastructure question — what hosting stack actually carries a BAA?

Most “HIPAA-compliant” platforms share the same core cloud providers, but the exact services vary — and BAA coverage is service-specific, not provider-wide. Google Cloud, for example, publishes a list of HIPAA-eligible products that specifically includes Firebase Hosting, Cloud Run, Firestore, Firebase Authentication, Cloud Storage, and many others, but does not include every product in the catalog.[7] A platform that is mostly HIPAA-eligible but routes through a single un-covered service has a hole.

Two architectural patterns break BAA coverage quietly:

• Un-covered CDN or edge-network in the request path. If the edge provider does not sign a BAA, or if the provider does sign a BAA but the specific product in use is not on the provider’s eligible list, the path is non-compliant even if the backend is spotless.
• Third-party analytics or monitoring scripts loaded on PHI-bearing pages. The marketing page is fine. The clinical surface is not. A platform that cannot separate those two surfaces cleanly should not be carrying PHI.

How NeuroPath is architected

NeuroPath runs end-to-end on BAA-covered Google Cloud services. The marketing surface (the main website, the hospital product page, the family product page) is hosted on Firebase Hosting. The clinical API and the staff-facing application are hosted on Cloud Run, with Firebase Authentication for identity and session management.

• 15-minute automatic logoff on the staff portal, meeting 45 CFR 164.312(a)(2)(iii).
• Encryption at rest (Google-managed keys with optional customer-managed keys for enterprise pilots) and in transit (TLS 1.2+).
• Audit logging on every read, write, and export of clinical data, retained for 6 years by default to match HIPAA retention expectations and most state medical-record retention laws.
• No third-party analytics on the clinical surface. The marketing surface uses privacy-respecting analytics with no PHI and no cross-domain linkage.
• No edge or CDN in the PHI request path. The clinical API resolves directly to Cloud Run; the old Cloudflare edge was retired as part of the Google-only migration.
• Back-to-back BAAs with every subprocessor (currently a short list: Google Cloud, our outbound transactional mail provider). The subprocessor list is published at /trust.

Procurement checklist — 12 questions to ask any behavioral-health vendor

1. Will you sign a BAA before any PHI moves? Can we see the template?
2. Which specific cloud services carry your PHI, and can you confirm each is on the provider’s HIPAA-eligible products list?
3. Is there a CDN, reverse proxy, or edge network in the request path for PHI traffic? If yes, is it BAA-covered for the specific product in use?
4. What is the automatic-logoff timeout on clinician-facing surfaces?
5. Can we see a sample audit-log export?
6. What is your audit-log retention period, and is it configurable?
7. How does your platform represent parental authorization, including state-law exceptions where a minor has independent consent rights?
8. If a record lives in both a clinical setting (HIPAA) and a school setting (FERPA), how does your platform represent the jurisdictional split?
9. Do you run third-party analytics or monitoring scripts on any clinical-facing page?
10. Who is on your subprocessor list, and is it published?
11. When was your last risk analysis, and will you share the executive summary?
12. If you experience a breach, what is your notification timeline and will it meet our 60-day downstream reporting obligation?