Navigating FDA and MDR Compliance: Managing the Device Lifecycle and Embedded Software Updates in Medical Devices - Dr. Baya Oussena

1. Introduction

The FDA and MDR are regulatory frameworks for medical devices, focusing on safety, efficacy, and quality, but differ in scope and implementation. The FDA oversees the US market with premarket approval, risk classification, and post-market surveillance. The MDR, enforceable across the EU, is stricter than the previous Medical Device Directive, emphasising clinical evaluation, Unique Device Identification, and Post-Market monitoring. Covering the entire device lifecycle, these regulations place more responsibility on manufacturers, especially for software-driven and high-risk devices. Understanding both is crucial for achieving global market access and maintaining long-term compliance.

Both the FDA and MDR processes assess device compliance before marketing. The FDA has two pathways: 510(k) for moderate risk, where manufacturers must demonstrate substantial equivalence to an existing device, which the FDA reviews without third-party involvement; and PMA for high-risk devices.  At the same time, MDR involves a more rigorous assessment and documentation across all risk levels.

2. Overview of FDA and MDR Processes

The FDA and MDR aim to safeguard patient safety, but the MDR is more prescriptive and lifecycle-focused in its approach to clinical evidence and post-market surveillance. Manufacturers must understand these nuances to meet compliance requirements and access both markets. Familiarity with these processes is crucial for complying with regulations and ensuring the safe and effective delivery of medical devices.

2.1 MDR Framework

Under the MDR, the conformity assessment process depends on device risk classification: low-risk Class I devices can self-assess, while higher-risk devices require Notified Body certification, which evaluates technical documentation, clinical data, and regulatory compliance. This documentation must demonstrate full compliance with all MDR safety and performance requirements before marketing.

2.1.1    MDR Key Regulation and Guidance

• MDR EU 2017/745: replaces  MDD-93/42/EEC with requirements that directly influence design and development processes. It introduces stricter controls on clinical evidence, more comprehensive technical documentation, and ongoing post-market surveillance.
• General Safety and Performance Requirements – GSPR (Chapter II, Annexe I): Similar to the FDA’s design controls, this approach includes software validation and clinical evidence.
• Post-Market Surveillance and Vigilance (Chapter VII, Annexe III): Mandates systematic monitoring, incident reporting, and field safety corrective actions.
• Unique Device Identification - UDI (Annexe III, Annexe I): Mandatory for traceability, including software versions to ensure full traceability across production, deployment, and field operations.
• EUDAMED: European Database on Medical Devices — essential for transparency and tracking.
• MDCG Guidance: The Medical Device Coordination Group (MDCG) issues approved guidance documents to ensure consistent interpretation and implementation of the MDR. These include crucial clarifications on clinical evaluation, software qualification, cybersecurity, PMS, and other key areas, serving as best practices when preparing regulatory documentation and demonstrating compliance.

2.1.2    MDR Processes:

1. Device Classification (Chapter V, Annexe VIII): Devices are classified into four classes (I, IIa, IIb, III) based on risk, with higher-risk devices needing stricter regulation assessment.
2. Conformity Assessment (Chapter V, Annexe IX, X, XI): Manufacturers must select a conformity assessment route based on the class, often involving a Notified Body for higher-risk cases.
3. Technical Documentation (Chapter II, Annexe II): Manufacturers must compile comprehensive technical documentation demonstrating compliance with MDR requirements.
4. Clinical Evaluation (Chapter VI, Annexe XV): Preparing a clinical evaluation report usually involves collecting clinical data or conducting studies to demonstrate the device’s safety and performance.
5. Labelling and Post-Market Surveillance (Annexes I, II, III, XIV Part B): Devices must be labelled in accordance with the MDR regulation. Post-market surveillance systems are required to monitor device performance after the device is released to the market.

2.2    FDA Framework

The FDA process differentiates between moderate- and high-risk devices. Most moderate-risk devices (Class II) follow the 510(k) notification process. High-risk devices (Class III) require Premarket Approval (PMA), a rigorous pathway that demands extensive evidence, including clinical trial data, to demonstrate safety and effectiveness.
For the 510(k) pathway, a device must be 'substantially equivalent” to an existing marketed device. If no equivalent exists, manufacturers may reclassify their device as lower risk and submit evidence, such as technical data and clinical studies, to demonstrate its safety and performance. Without equivalence, the FDA might require a Premarket Approval (PMA) review, which is more rigorous.

FDA Key Regulation and Guidance:

• 21 CFR Part 820 (Quality System Regulation – QSR): Clarifies essential quality management requirements, including design controls, verification and validation (V&V), and change management procedures.
• 21 CFR Part 11: Applies to electronic records and signatures, especially relevant for software development tools and digital traceability systems.
• FDA Guidance on Software: Multiple guidance documents cover Software as a Medical Device (SaMD), software modifications, cybersecurity, and artificial intelligence/machine learning-based software.

2.2.2    FDA Processes:

1. Device Classification: Devices are categorised into three classes (I, II, III) based on risk. Higher-risk devices require a more rigorous review of requirements.
2. Premarket Notification (510(k)): For devices that are not Class III, manufacturers must prove their device is substantially equivalent to a legally marketed device.
3. Premarket Approval (PMA): High-risk Class III devices require a PMA, which involves a thorough review process to ensure their safety and effectiveness.
4. Clinical data might be necessary for both 510(k) and PMA submissions to prove device performance.
5. Labelling and Post-Market Surveillance: Devices must meet FDA labelling requirements and have systems for continuous performance monitoring.

3. Main Struggles for Medical Device Makers

Securing market approval and maintaining a presence is tough due to navigating compliance, managing documents, and adapting to changing standards. Startups and device manufacturers often struggle with the US FDA or EU MDR regulations. It can be complex to understand the requirements for each device class, including SaMD or embedded software, which can lead to wasted resources, missed deadlines, or rejected submissions. Companies face several key challenges, including:

3.1 Documentation Overload and Audit Readiness

Keeping comprehensive, structured documentation is no longer a choice. Both the FDA and MDR require detailed traceability from user needs down to source code and verification tests. This includes:

• Design History Files (DHF) and Device Master Records (DMR) for the FDA.
• Technical documentation per the GSPR under MDR
• Evidence of software validation and usability testing.
• Ensure robust version control and maintain audit trails for all updates.

Challenge: getting all stakeholders, including R&D, regulatory, and QA, to work together in real-time to produce auditable and consistent records throughout the development and maintenance phases.

3.2 Managing Software Changes and Risk Re-Evaluation

Software rarely remains unchanged after approval. Updates often involve bug fixes, usability improvements, cybersecurity patches, and upgrades to AI models. 
According to the MDR, even minor software updates can trigger a “significant change', requiring re-certification by a notified body. The FDA demands risk-based justification for any change and expects a comprehensive analysis of the impact on safety and effectiveness.
Challenge: balancing agility with regulatory rigour, ensuring that product teams can implement timely updates without causing compliance delays or incurring regulatory penalties.

3.3 Classification and Reclassification of Software

Under the MDR, many standalone software products are now classified as higher risk, such as a mobile app previously classified as Class I under MDD, which may now be classified as Class IIa or IIb (e.g., Diabetes Management App). This requires additional clinical data, testing, and involvement from the notified body.
Challenge: Many manufacturers are caught off guard by these shifts, especially those with legacy devices or minimal in-house regulatory support.

3.4 Legacy Devices and Retrospective Compliance

Devices already on the market before the MDR came into force may no longer meet current standards, especially in areas such as cybersecurity, software validation, and post-market surveillance.
Challenge: deciding whether to update and re-certify legacy systems (which may require major documentation overhauls) or sunset them, often at significant cost to the company.

3.5 Post-Market Surveillance and Vigilance

Both the FDA and MDR now require ongoing monitoring of device performance, safety, and user feedback. Software anomalies or cybersecurity incidents must be documented, thoroughly investigated, and, in some cases, reported.
Challenge: building scalable monitoring systems that integrate with internal quality processes while maintaining clear traceability between field data, risk files, and software updates.

3.6 Staying Aligned with Constantly Evolving Standards

Regulatory standards in software aren't fixed; they, like IEC 62304 or ISO 14971 for risk management, are regularly updated. Manufacturers must stay current, especially with long cycles or legacy systems that may have become outdated.
Challenge: staying up to date to avoid non-compliance.

3.7 Audit Readiness and the Documentation Overload

As regulators increase scrutiny and audits become more frequent, maintaining audit readiness is essential. This requires maintaining traceability matrices, version-controlled records, and documentation of design decisions, risk assessments, and change management activities to ensure they are up-to-date and accurate. The volume and complexity of this documentation often pose challenges to quality and regulatory teams.
Challenge: increasing volume and complexity of documentation.

4. FDA and MDR Regulations: Conclusion and Call to Action

For medical device manufacturers, complying with medical device regulations is a strategic necessity that impacts market access, patient safety, and brand reputation.. 
From an executive perspective, ensuring regulatory compliance for software involves the following:

• End-to-end visibility and traceability across the entire software lifecycle: Leadership must ensure that all software activities, from requirements gathering to decommissioning, are documented, traceable, and compliant with regulations. This transparency supports audits and risk management.

• Organisations should follow a structured, well-governed software development process, using a lifecycle-based model documented in a Software Development Plan (SDP). This plan outlines the methodology, quality assurance, risk mitigation, and regulatory checkpoints, ensuring more predictable, repeatable, and compliant development.

• Proven control over software changes and quality: Authorities require evidence of complete control over software assets, including tracking bugs, incidents, patches, updates, and managing configurations. These measures reduce compliance risks, prevent recalls, and ensure device reliability.

Incorporating EU MDR and U.S FDA. Requirements in the software development culture demonstrate leadership's commitment to quality, ensure regulatory approval, and support sustainable innovation in the medical device market. 
It's a complex path, but with the right tools, teams, and mindset, it remains accessible and ultimately transformative. 

A software update is considered regulated if it affects the device’s intended use, performance, safety, data processing, clinical outputs, user interface, connectivity, cybersecurity, or involves retraining or redeploying AI/ML models. Such updates are typically classified as major changes, requiring re-verification, re-validation, and regulatory approval. 

For this discussion, we will present three case studies —one on epilepsy, the second on kidney disease and the third on wearable patches—featuring high-risk devices regulated by the FDA and MDR. To improve realism, we based these on existing market devices: the NeuroPace RNS and the Automated Peritoneal Dialysis device, both of which are FDA-approved [RNS_FDA] and [APD_FDA], respectively, and Epicore’s Connected Hydration Patch, offering SOC 2 Type II cloud compliance features and hazardous environments (Class I, Div 2) certified. 

The software updates in the cases are fictional and intended solely for educational purposes, helping readers understand the device and software lifecycle updates in accordance with FDA and MDR standards.

Before reviewing these use cases, let's revisit a structured summary of best practices for managing device and software lifecycle updates in line with FDA and MDR regulations.

1. Understand the Device & Software Lifecycles

2. Determine the Type of Change

 Change Classification & Risk Analysis:

• Conduct a risk assessment to classify the update (e.g., bug fix, UI change, algorithm adjustment)  
• Determine whether the update is a minor or major change.

Key Questions:

• Is the software update safety-critical? 
• Does it impact clinical functionality, algorithms, communication protocols, or cybersecurity?

Use:

• MDCG 2020-3 Rev.1 for EU significant change guidance
• FDA Guidance: “Deciding When to Submit a 510(k) for a Software Change to an Existing Device”

3. Regulatory Decision Tree

4. SELECT Lifecycle Management Tools for Compliance

The following tools ensure traceability, testing, and continuous compliance:

• Jira – Tracks change requests, user stories, and risk items.
• Confluence – Central hub for architectural specs, cybersecurity strategy, and regulatory evidence.
• Polarion – Offers end-to-end traceability across requirements, risks, test cases, and verification evidence, aligned with IEC 62304 and ISO 14971.
• Git – Maintains full code history and release tagging.
• Jenkins – Manages automated testing pipelines and logs.
• eQMS / Greenlight Guru – Supports alignment with regulatory artefacts and design history.

These tools are integrated for:

• Bidirectional traceability
• Real-time change tracking
• Complete audit readiness

The device under discussion is a Responsive Neurostimulator System, an implantable electromechanical medical device designed to monitor brain activity and deliver targeted electrical stimulation to prevent or reduce seizures in patients with drug-resistant epilepsy.

1. Device Context Overview

The Responsive Neurostimulator device contains embedded components, including microcontrollers, sensors, stimulators, processors, and secure memory, to monitor and respond to abnormal brain activity. Its embedded software, classified as Software in a Medical Device (SiMD) and Category C under IEC 62304, supports life-saving functions and has an impact on neurological health. Features include real-time EEG analysis, seizure precursor detection, adaptive neurostimulation, and long-term data logging. It may also facilitate data transmission and remote monitoring through secure telemetry, wireless interfaces, or cloud-based systems. The target markets are the US, regulated by the FDA, and the EU under MDR.

Responsive neurostimulator devices are classified as Class III under the FDA (e.g., 21 CFR  882.5800 – Cranial electrotherapy stimulator) and as Class III under MDR Rule 9 (active implantable devices intended to deliver energy to the central nervous system).

In this scenario, we consider introducing a new software update to:

• Enhance responsiveness to atypical seizure onset patterns identified in recent clinical data.
• Integrate behavioural and sleep data from a patient-wearable device to dynamically adapt stimulation thresholds.

This scenario highlights the complexity of implementing algorithm updates in a neurostimulator implanted in the skull, which must ensure patient safety, clinical performance, and full compliance with FDA and MDR regulations.

2. Impact Assessment

This software update introduces significant changes that affect core components:

• Therapeutic Logic: A new algorithm logic alters how seizures are detected and stimulation is delivered, directly affecting clinical performance and requiring formal verification and validation.

• External Data Ingestion: The inclusion of sleep or activity data introduces new communication pathways and increases cybersecurity risk, necessitating robust threat mitigation and data validation strategies.

• User Interface (Clinician Dashboard): Updates to data visualisation, alert thresholds, or patient programming must be captured in human factors engineering documentation and reflected in Instructions for Use (IFU).

3. Regulatory Considerations

UNDER FDA:

• A new 510(k) submission is likely due to the altered seizure detection logic influencing treatment timing and efficacy

• Full traceability from design inputs to verification activities must be maintained under 21 CFR 820.30

UNDER MDR:

• The device’s functionality and intended purpose are affected, triggering a Notified Body review

• Updates required for Technical Documentation, Clinical Evaluation Report (CER), UDI, and PSUR

• A new Basic UDI-DI may be required if the device’s mode of action is altered

4. Software Lifecycle Activities (IEC 62304 Mapping)

5. Cybersecurity Integration

• TLS Upgrade: Latest TLS protocols implemented for secure transmission between the implanted device and the external programming system

• System Hardening: Memory protections and sandboxing techniques are applied to isolate the updated algorithm

• Secure OTA Updates: Cryptographically signed over-the-air (OTA) update mechanism for the clinician’s programmer

• Expanded Threat Modelling: BLE vulnerabilities and risks of data interception from wearable integration assessed in updated threat model

Cybersecurity upgrades comply with the latest version of the FDA Premarket Cybersecurity Guidance and MDR GSPR, and are documented in the Software Update File (SUF).

6. Post-Market and Clinical Considerations

The EU MDR 2017/745 & FDA 21 CFR updated as follow:

• Post-Market Surveillance: PSUR and vigilance reports updated (MDR Article 86; 21 CFR  820.198)

• Clinical Evaluation: Ongoing PMCF studies updated with new EEG and seizure classification accuracy data (MDR Annexe XIV)

• Labelling & IFU: Updates to clinician documentation to reflect new algorithm logic and programming features (GSPR 14, 23; 21 CFR 801)

A peritoneal device typically refers to equipment used in peritoneal dialysis (PD), a treatment for kidney failure that utilises the peritoneum—the abdominal lining—as a natural filter to remove waste and excess fluid from the blood. 

1. Device Context Overview

The device in question is a Peritoneal Dialysis Cycler, an electromechanical medical system that automates dialysis therapy for patients. It incorporates key embedded components, including a microcontroller, various sensors, actuators, and memory modules, to manage and regulate the treatment process. The software controlling the device is embedded, classifying it as a Software in a Medical Device (SiMD), and is considered Class C under the IEC 62304 standard due to its crucial role in patient safety. Main features include automatising dialysis cycles—covering filling, dwelling, and draining phases—while consistently monitoring therapy parameters and recording vital data. Furthermore, the device may include connectivity functions such as data logging and remote monitoring via cloud services, Bluetooth, or Wi-Fi, depending on the configuration. The primary regulatory markets for this device are the United States, regulated by the FDA, and the European Union, under the Medical Device Regulation (MDR). 

PD devices are classified as Class II (21 CFR 876.5630 – Peritoneal dialysis system and accessories) under the FDA and as Class IIb (Rule 10 or Rule 22 for active therapeutic devices that administer or remove body fluids) under the MDR.

In this scenario, we consider introducing a new software update to:

• Enable real-time remote monitoring of the therapy sessions via a secure cloud dashboard.
• Trigger clinician alerts when therapy deviates (e.g., incomplete drain cycles, flow anomalies).

This update highlights the complexity of implementing connected features in a safety-critical system, requiring rigorous validation, robust cybersecurity, and compliance with both FDA and MDR standards.

2. Impact Assessment

This software update introduces significant changes affecting key components:

• Communication Module Expansion: adds a telemetry layer to securely transmit session data (volumes, flow rates, alerts) to the cloud, improving data transfer and requiring encryption, latency management, and failure recovery.

• Alert Logic Engine: Adds a real-time layer to detect issues during therapy and notify the care team, but introduces clinical risk requiring careful validation.

• User Interface and IFU: Patients can see new indicators or alerts, and clinicians can access therapy data remotely. These updates need a revised UI design, usability testing, and an updated IFU.

3. Regulatory Considerations

UNDER FDA:

• The new connectivity and alerting features are likely to require a 510(k) because of potential changes in clinical performance impacts. It may influence the device’s safety profile.
• Full design controls must be maintained and updated in accordance with 21 CFR 820.30.

UNDER MDR:

• The added remote monitoring features affect the device’s interaction with external systems and its risk profile, prompting a Notified Body review.
• The technical documentation, clinical evaluation, and the PSUR must accurately reflect these functional extensions.
• A new Basic UDI-DI might be necessary if the added features substantially alter the intended use.

4. Software Lifecycle Activities (IEC 62304 Mapping)

5. Cybersecurity Integration

• End-to-End Encryption: Securely transmit device therapy data to the cloud using the latest TLS protocols and mutual authentication for enhanced security.
• Zero Trust Framework: Device identity and session-level authentication prevent unauthorised data access.
• Firewall and Access Rules: The device's OS is hardened to restrict open ports and block remote commands, except for secure OTA updates.
• Threat Model Update: New risks such as MITM (Man-in-the-Middle) attacks, data spoofing, and alert flooding have been identified and mitigated.

Cybersecurity upgrades align with the FDA Premarket Cybersecurity Guidance and MDR GSPR 17.4, and are recorded in the Software Update File (SUF).

6. Post-Market and Clinical Considerations

The device update fully complies with EU MDR 2017/745, particularly Annexes I, II, III, and XIV, and conforms to the essential FDA regulations outlined in 21 CFR Parts 820.100, 820.198, 807, and 812, Subpart H.

• Post-Market Surveillance (PMS): The PSUR now encompasses remote monitoring metrics, such as false-positive and false-negative alert rates, alongside real-world data from early clinical deployments. U.S. FDA PMS documents adhere to 21 CFR 820.100 and 820.198.
• Clinical Evaluation and PMCF Reports evaluate the usability, reliability, and safety of remote therapy and are cited in FDA submissions, such as 510(k) or PMA, for traceability.
• Labelling and Instructions for Use (IFU): Updates include remote access setup, alert protocols, and troubleshooting to ensure compliance with MDR GSPRs 14 and 23, as well as FDA 801.

Let’s consider, in the present use case, a hypothetical software update scenario for the Epicore Biosystems’ Connected Hydration Patch and examine how this update would be managed under both the EU MDR (Regulation EU 2017/745) and the US FDA (21 CFR Part 820, including software guidance) throughout the software/device lifecycle.

1. Device Context Overview

The Connected Hydration Patch is a skin-attached sensor that monitors sweat biomarkers, including fluid loss, sweat rate, and electrolyte levels (especially sodium), using microfluidic technology. It wirelessly sends data to a smartphone, helping athletes, workers, and patients optimize hydration, reducing risks like dehydration and overhydration. 

The Epicore Connected Hydration Patch has a layered design combining embedded firmware, mobile apps, and secure cloud platform to provide real-time hydration and temperature data.

The electronics module of the hydration patch operates on low-power firmware to perform sensing, processing, and communication tasks. It controls sensors for sweat rate, skin temperature, and motion, buffers collected data, transmits information via BLE, and activates vibration alerts to signal dehydration, providing users with real-time feedback.

The mobile app, available on iOS and Android, connects to the hydration patch via Bluetooth Low Energy (BLE), displaying real-time hydration and temperature data, alerting users when levels are low, and synchronising data with a secure cloud for analysis, tracking, and reporting.

At the enterprise level, Epicore provides a SOC 2 Type II-certified cloud infrastructure designed to support secure and scalable hydration monitoring.

In this scenario, we consider introducing a new software update to:

• Integrate sleep tracking data to predict the risk of early-morning dehydration.
• Provide personalised pre-sleep hydration suggestions and post-sleep alerts.

The proposed sleep-aware dehydration forecast demonstrates how wearables are evolving into smarter, preventive health tools. Devices now do more than monitor; they manage risks, ensure transparency, and engage users. To innovate responsibly, updates must use validated data, real-world feedback, and robust controls. Incorporating external health data like sleep metrics into medical-grade wearables presents challenges, stressing the need for usability testing, clinical validation, and proper regulation, especially after updates affecting risk alerts and decision support.

2. Impact Assessment

This software update introduces multiple critical changes:

• Prediction Algorithm Logic: The algorithm now includes circadian patterns, sleep duration, and recovery scores to forecast dehydration risk upon waking, introducing new variables and scenarios that require hazard analysis and verification.
• Data Integration Pipeline: The patch and app now accept sleep data from third-party APIs (e.g., Apple Health, Google Fit). This adds dependency complexity, error handling requirements, and privacy obligations.
• User Interface and IFU: Personalised sleep–hydration insights, alerts, and instructions require a redesign of the mobile app interface and updates to the Instructions for Use (IFU). These changes must undergo usability validation and risk traceability mapping to ensure their effectiveness and efficacy.

3. Regulatory Considerations

UNDER FDA:

• The addition of a sleep-based risk engine may trigger a 510(k) if it alters how dehydration risk is calculated or communicated, particularly if it is linked to medical advice.
• The entire update must be documented by 21 CFR 820.30, including requirements, verification and validation (V&V) activities, and design outputs.

UNDER MDR:

• The new predictive feature alters how the device interprets and reports physiological conditions, necessitating a Notified Body review.
• Updates are needed for the Technical Documentation, CER, UDI, and PSUR.
• A new Basic UDI-DI might be needed if the device’s intended purpose is deemed expanded to include sleep-related risk warnings.

4. Software Lifecycle Activities (IEC 62304 Mapping)

The update spans multiple areas in the software lifecycle:

5. Cybersecurity Integration

• App-Level Permissions Control: Fine-grained permission requests for accessing third-party sleep data; user authorisation is logged and revocable.
• Data Integrity Checks: Sleep data timestamps and sync quality are verified before use in predictions.
• Privacy Risk Mitigation: All imported data is anonymised and stored separately from biometric hydration data.
• Threat Modelling Update: New threat vectors, API hijacking, stale data injection, and mobile app spoofing—addressed in the latest model.

All measures adhere to the latest version of the FDA Cybersecurity Guidance and MDR GSPR.

6. Post-Market and Clinical Considerations

In alignment with EU MDR 2017/745 – Annexes I, II, III, and XIV; and FDA 21 CFR Parts 820.100, 820.198, 807, and 812 Subpart H:

• Post-Market Surveillance (PMS): Updated PSUR includes false alert rates, user complaints, and real-world usage data. For the FDA, surveillance data are logged under 21 CFR 820.198 and 803.
• IFU and App Labelling: New sections describe the role of sleep data, limitations of predictions, and instructions for optimal hydration before sleep. Compliant with 21 CFR 801, GSPR 1, 14, and 23.
• Clinical Evaluation and PMCF: The predictive accuracy, usability, and effectiveness in reducing dehydration events are evaluated through PMCF studies under MDR Annexe XIV and the FDA’s post-market pathways.

7. When Smart Features Require Smarter Compliance

Epicore’s connected hydration system, in its current configuration, is not certified under the EU Medical Device Regulation (MDR) and lacks FDA clearance as a medical device. Existing certifications pertain to industrial safety and data security but do not constitute conformity to EU MDR requirements (e.g., Annexe I, GSPR) or U.S. regulatory frameworks under 21 CFR Part 820. Any extension of intended use that includes physiological monitoring or health-related risk prediction may trigger reclassification under MDR Article 2(1) or the FDA’s Section 201(h) of the FD&C Act.

The hypothetical addition of a Sleep-Aware Dehydration Risk Prediction feature represents a substantial functional enhancement. This change introduces algorithm-based risk stratification using sleep pattern data and hydration metrics, potentially crossing the threshold from a general wellness device to a regulated Software as a Medical Device (SaMD). Under MDR, this may result in a reclassification to Class IIa or higher (as per MDCG 2021-24), triggering complete technical documentation requirements (Annexes II & III) and a conformity assessment via a Notified Body. Under FDA regulations, this modification may necessitate a 510(k) submission or De Novo classification, depending on the presence of predicates and the risk profile.

Given its robust hardware infrastructure and advanced data analytics capabilities, Epicore’s system is well-positioned technically to transition toward regulated medical use. However, such a transition demands a structured approach to clinical validation, regulatory engagement, software lifecycle documentation, and post-market surveillance planning. Continuous monitoring of the product’s regulatory status is essential as predictive features evolve and approach the boundary of regulated clinical functionality.