Executive Summary
A digital-health company was developing an artificial-intelligence platform intended to analyze patient information and generate risk-based clinical insights for healthcare professionals.
The development team initially described the product as a general wellness and decision-support application. However, the proposed functions included analysis of medical information, identification of clinically meaningful patterns, prioritization of cases, and recommendations that could influence patient management.
These functions created a credible possibility that the software would meet the definition of a medical device and require FDA premarket authorization.
E&E Medicals evaluated the product function by function, separated potentially non-device features from regulated medical-device functions, refined the intended-use statement, assessed SaMD risk, researched possible product classifications and predicates, and developed an FDA regulatory roadmap.
The resulting strategy identified a potentially viable premarket pathway, established the evidence needed to support the AI-enabled functions, and prevented the company from relying on an unsupported “wellness software” position.
Client Situation
The client was an early-stage digital health company developing a cloud-based platform that combined:
• Patient-reported symptoms
• Medical history information
• Physiological measurements
• Wearable-device information
• Laboratory results
• AI-generated pattern detection
• Risk prioritization
• Clinician-facing summaries
• Patient-facing educational information
Product development was already underway, but the company had not established:
1. Which functions were regulated medical-device functions
2. Whether any clinical-decision-support exclusion applied
3. The likely FDA classification
4. Whether a predicate device existed
5. Whether a 510(k), De Novo request, PMA, enforcement-discretion position, or non-device rationale was appropriate
6. Whether the algorithm was locked or adaptive
7. What analytical and clinical validation would be required?
8. How future model changes would be controlled
Regulatory Problem
The regulatory status of software depends on its intended use, users, inputs, outputs, level of automation, clinical significance, and how the output affects clinical decisions.
Calling a product “wellness software” does not make it non-regulated when its actual functions are intended to diagnose, screen, predict, monitor, or guide treatment of a disease or condition.
The product also included different functions with different regulatory profiles. Treating the entire platform as either wholly regulated or wholly unregulated would have produced an oversimplified and potentially indefensible strategy.
Additional concerns included:
• Ambiguous intended-use language
• Disease-related promotional claims
• Limited transparency into the algorithm’s basis
• Lack of an established predicate strategy
• Incomplete AI lifecycle controls
• Unclear training-data provenance
• Potential subgroup-performance differences
• No predetermined change-control framework
• Limited cybersecurity documentation
• No formal design-history structure
E&E Medicals’ Role
E&E Medicals served as the AI/SaMD regulatory strategy partner, supporting:
• Function-by-function regulatory assessment
• Device versus non-device determination
• Clinical-decision-support analysis
• Intended use and claims development
• IMDRF SaMD risk categorization
• FDA classification and product-code research
• Predicate and regulatory-history assessment
• 510(k), De Novo, and PMA pathway evaluation
• Q-Submission strategy
• AI data-governance assessment
• Analytical and clinical validation planning
• Human factors and cybersecurity planning
• Design-control implementation
• Risk-management integration
• Predetermined Change Control Plan planning
Work Completed
1. Software-function inventory
The platform was divided into individual functions rather than evaluated as one undifferentiated product.
Function Preliminary regulatory concern
General education Potentially non-device
Wellness tracking Potentially general wellness
Data aggregation Depends on transformation and claims
Trend presentation Depends on clinical interpretation
Risk scoring Potential device function
Disease-specific alert Likely heightened device concern
Case prioritization Potential device function
Treatment recommendation High regulatory significance
Clinician summary Depends on whether the basis is independently reviewable
This analysis enabled the company to place regulated functions inside an appropriate quality and regulatory boundary while separately managing lower-risk features.
2. Intended-use and claims remediation
E&E Medicals reviewed product requirements, investor materials, website language, interface text, and planned marketing claims.
Ambiguous expressions such as “detects problems before symptoms appear” were replaced with language that accurately reflected the evidence and intended function. Launch-essential claims were distinguished from aspirational future claims.
3. Classification and pathway assessment
The team evaluated:
• Applicable device classifications
• Potential product codes
• Comparable cleared and authorized products
• Similarities in intended use
• Algorithm inputs and outputs
• Target population
• Intended user
• Clinical setting
• Level of automation
• Consequences of incorrect output
• Need for independent clinical review
• Availability and quality of predicates
The assessment produced a preliminary pathway recommendation and identified questions requiring FDA feedback.
4. AI evidence framework
A staged evidence program was developed to address:
• Training, validation, and test-data separation
• Data provenance and representativeness
• Reference-standard definition
• Missing data handling
• Model performance
• Sensitivity and specificity, where applicable
• False-positive and false-negative consequences
• Subgroup performance
• External validation
• Site-to-site generalizability
• Human-AI interaction
• Model monitoring
• Drift detection
• Cybersecurity
• Change control
5. PCCP planning
For anticipated postmarket model modifications, the team developed a preliminary PCCP framework covering:
• Modification Description
• Modification Protocol
• Impact Assessment
• Permitted model changes
• Data acceptance criteria
• Retraining controls
• Validation requirements
• Performance boundaries
• Rollback criteria
• Monitoring and reporting
FDA’s final PCCP guidance describes how an authorized PCCP can address planned modifications to AI-enabled device software functions while maintaining reasonable assurance of safety and effectiveness. FDA PCCP guidance
6. Q-Submission preparation
Focused FDA questions were developed concerning:
• Device and function classification
• Proposed premarket pathway
• Predicate suitability
• Clinical-study expectations
• Performance endpoints
• Subgroup analysis
• Human factors testing
• PCCP scope
• Cybersecurity documentation
Measurable Outcome
Because this is an illustrative case, the appropriate measurable outcomes are documented work products rather than unsupported commercial or FDA results:
• One controlled inventory of all software functions
• Each function assigned a preliminary regulatory status
• One approved intended-use framework
• One classification and pathway memorandum
• One predicate and comparable-device assessment
• One AI evidence-gap matrix
• One preliminary PCCP framework
• One Q-Submission question set
• Defined regulatory gates integrated into product development
• High-risk claims identified before public launch
.png)