AI-Driven Risk Prediction in Paediatrics: What RA Teams Must Know

The emergence of an AI tool capable of estimating a child's risk of developing ADHD, reported in this week's Digital Health briefing, represents far more than an interesting clinical development. It's a regulatory stress test. Predictive algorithms that assess future disease risk in paediatric populations sit at the confluence of multiple regulatory complexities: software classification, clinical evidence requirements for predictive claims, special population considerations, and the evolving regulatory framework for AI/ML-enabled devices. For regulatory affairs teams, this isn't just another software device to classify—it's a case study in how the regulatory landscape is struggling to keep pace with algorithmic medicine.

The Classification Challenge: Where Does Risk Prediction Sit?

Under both EU MDR and MHRA regulations, the classification of this type of device hinges on its intended purpose and the nature of the information it provides. An AI tool that estimates future ADHD risk is almost certainly providing information used to make decisions for diagnostic or therapeutic purposes. Under MDR Rule 11, software intended to provide information which is used to make decisions with diagnosis or therapeutic purposes is classified as Class IIa—unless such decisions have an impact that may cause death or an irreversible deterioration of a person's state of health, in which case it becomes Class IIb, or serious deterioration or a surgical intervention, making it Class III.

Here's where it gets interesting for ADHD risk prediction: the downstream clinical pathway matters enormously. If the tool's output directly influences whether a child receives medication (stimulants carry cardiovascular and psychiatric risks), or conversely, if a false negative delays intervention during critical developmental windows, you're potentially looking at Class IIb territory. The clinical context isn't peripheral to classification—it's central. For manufacturers, this means your classification rationale must comprehensively map the clinical decision pathway and potential patient harm scenarios, not just describe the algorithm's output.

The FDA's approach differs but creates similar complexity. Under the agency's 21st Century Cures Act provisions and subsequent guidance on Clinical Decision Support software, the key question is whether the tool is intended to enable healthcare professionals to independently review the basis of recommendations. A 'black box' AI providing a risk score without interpretable features could face a more stringent regulatory pathway than one offering transparent risk factors that clinicians can evaluate. This fundamental design choice—transparency versus pure predictive performance—has direct regulatory consequences that should inform development from the earliest stages.

The Paediatric Evidence Problem

Predictive algorithms for paediatric conditions face a particularly thorny evidence challenge. Clinical evaluation under MDR Annex XIV requires sufficient clinical evidence to demonstrate safety, performance, and benefit-risk ratio. But how do you generate clinical evidence for a prediction about a future condition? Traditional diagnostic device validation compares device output against a reference standard in patients with confirmed disease. Predictive tools require longitudinal studies following children over years to validate whether the algorithm's risk estimates correlate with actual ADHD development.

This creates a temporal paradox for market access: you need extensive longitudinal data for robust clinical evaluation, but gathering that data requires either waiting years before submitting a technical file, or launching with provisional data and committing to post-market surveillance that genuinely tracks predictive validity. The latter approach aligns with MDR's emphasis on continuous evidence generation, but it requires manufacturers to design PMCF that goes beyond typical device follow-up. You're not just monitoring device failures or adverse events—you're tracking whether your predictions materialise years later in a paediatric population where consent, data protection, and loss-to-follow-up all present amplified challenges.

Moreover, ADHD diagnosis itself lacks a definitive biomarker; it's a clinical diagnosis based on behavioural criteria that evolve with DSM and ICD revisions. Your AI's 'ground truth' for training and validation is therefore based on clinical judgment, creating a circular validation problem. Regulatory assessors will scrutinise how the training data was labelled, by whom, and whether the algorithm is truly predicting ADHD or simply replicating clinician bias patterns embedded in historical diagnosis records. The clinical evaluation report must address these epistemological challenges head-on.

The AI/ML Regulatory Framework Is Still Crystallising

Both the MHRA and EU Commission have published guidance on AI/ML medical devices, but significant grey areas remain—particularly for continuously learning systems and algorithmic updates. If your ADHD risk prediction tool incorporates new patient data to refine its models, when does an algorithmic update constitute a significant change requiring regulatory submission? The MHRA's Software and AI as a Medical Device Change Programme guidance attempts to address this, establishing a framework for predetermined change control plans, but implementation details remain works in progress.

The EU AI Act adds another regulatory layer. While MDR/IVDR govern medical device market access, the AI Act establishes horizontal requirements for high-risk AI systems—which explicitly include AI used in medical devices. This creates dual compliance obligations: your device must satisfy MDR requirements for safety and performance, and AI Act requirements for transparency, data governance, and human oversight. For a paediatric predictive tool, you're dealing with both a high-risk medical device and a high-risk AI system under separate regulations with overlapping but non-identical requirements.

Practically, this means your technical documentation must address AI-specific considerations that traditional device files don't cover: dataset representativeness and bias mitigation, algorithm validation across demographic subgroups, cybersecurity provisions for model integrity, and transparent information for users about the AI's limitations. These aren't abstract requirements—Notified Bodies are actively requesting this information, and incomplete responses are causing technical file review delays.

What This Means for Your Team

If you're developing predictive diagnostic tools—particularly for paediatric indications—several strategic considerations emerge from this example. First, engage with your Notified Body or regulatory authority early, ideally before finalising your clinical evaluation strategy. The classification and evidence requirements for predictive algorithms aren't always intuitive, and different assessors may interpret the rules differently. A pre-submission meeting or classification request can prevent costly pivots later in development.

Second, build your clinical evaluation strategy around longitudinal evidence from the start. Don't treat PMCF as an afterthought—it's potentially the most critical component of your evidence package for a predictive device. Design follow-up mechanisms that can actually track whether predictions prove accurate years later, and build in the infrastructure for data linkage with healthcare records or registries. This requires data protection impact assessments, consent mechanisms that contemplate long-term follow-up, and realistic planning for participant retention in paediatric populations.

Third, assemble your AI/ML documentation systematically from the outset. The tendency to treat algorithm development as separate from regulatory documentation creates integration problems later. Your design and development documentation should capture dataset composition, bias assessment, validation methodology, and performance across subgroups as integral components—not retrofitted summaries. The technical file for an AI device should tell a coherent story about how the algorithm was developed, validated, and implemented with appropriate risk controls throughout.

Fourth, consider the clinical utility question proactively. Regulatory approval requires demonstrating not just that your algorithm produces a risk score, but that this information provides clinical benefit. For ADHD risk prediction, what's the clinical intervention pathway for a child identified as high-risk? How does early identification change management, and is there evidence that earlier intervention improves outcomes? These clinical utility questions increasingly influence regulatory decisions, particularly for Class IIb and III devices. Your clinical evaluation should address them comprehensively.

Key Takeaways

• Classification of predictive AI tools depends critically on the clinical decision pathway and potential patient harm, not just the algorithm's output format—map downstream clinical use comprehensively in your classification rationale.
• Longitudinal clinical evidence is essential but challenging for predictive devices; design PMCF that genuinely tracks whether predictions materialise over time, with infrastructure for long-term paediatric follow-up built in from the start.
• Dual compliance with MDR and the EU AI Act creates overlapping documentation requirements for AI medical devices—address AI-specific considerations (dataset bias, algorithmic transparency, demographic validation) as integrated components of your technical file, not afterthoughts.
• Early regulatory engagement is particularly valuable for novel predictive tools where classification and evidence requirements aren't clearly precedented; pre-submission meetings can prevent expensive late-stage pivots.
• Clinical utility evidence increasingly influences regulatory decisions for diagnostic AI; demonstrate not just algorithmic performance but how the information meaningfully improves patient management and outcomes in your intended population.

The ADHD risk prediction tool highlights a broader truth: as medical devices become more algorithmic and predictive, the regulatory assessment shifts from evaluating a static device to evaluating an evidence generation and risk management system. Traditional device development separated design, validation, and post-market surveillance into sequential phases. AI-enabled predictive devices require these elements to function as an integrated continuous cycle. Teams that recognise this shift—and build their development and regulatory strategies accordingly—will navigate the evolving landscape more successfully than those applying traditional device frameworks to fundamentally different technology. As always, the regulatory challenge isn't just understanding the rules as written, but anticipating how they'll be applied to devices the drafters couldn't fully envision.