Why MDDS Classification Matters Before IDE Submission
Under current FDA guidance, software functions that meet the Medical Device Data System (MDDS) criteria are no longer FDA-regulated devices. This is the practical result of Section 3060(a) of the 21st Century Cures Act, signed into law on December 13, 2016, which amended section 520 of the Federal Food, Drug, and Cosmetic Act to remove certain software functions, including software-only MDDS, from the statutory definition of a “device.” FDA’s September 2019 final guidance formalized this position. Translation: if your medical device software qualifies as Non-Device-MDDS, FDA’s device regulations generally do not apply. That means no 510(k), no registration, no listing, and no post-market reporting requirements.
Why this matters for startup medical device teams preparing for Investigational Device Exemption (IDE) submission: the MDDS classification question is the fork in your regulatory roadmap. If your software is genuinely Non-Device-MDDS, you skip the IDE-to-clearance pathway entirely for the data-handling components of your system. If your software is actually Software as a Medical Device (SaMD), meaning it analyzes, diagnoses, treats, or drives clinical decisions, then IDE submission is part of your path to market. Getting MDDS-vs-SaMD wrong at the start either creates regulatory exposure you’ll have to remediate later (when SaMD is misclassified as MDDS) or wastes months on unnecessary submissions (when MDDS is misclassified as SaMD).
The classification decision is structured but requires honest assessment, since the consequences cut both ways. The examples and framework below walk through how to make the call, with concrete examples of software that does and does not qualify as MDDS.
What Qualifies as a Medical Device Data System Under 21 CFR 880.6310
FDA defines a Medical Device Data System narrowly in 21 CFR 880.6310. To qualify as MDDS, software must perform only data-handling functions, without analyzing or interpreting medical device data, controlling other medical devices, or providing alarms or alerts beyond a passive notification of a received transfer. The four allowable MDDS functions are:
1. Electronic transfer of medical device data. Moving data from one place to another. For example, transmitting glucose readings from a continuous glucose monitor to a smartphone app or cloud server. The software moves the data without modifying or analyzing it.
2. Electronic storage of medical device data. Saving medical device data for later retrieval. For example, archiving heart rate data from a wearable in a cloud database. Storage alone, without analysis, qualifies as MDDS.
3. Electronic conversion of medical device data from one format to another in accordance with a preset specification. Converting data formats. For example, transforming HL7 data into FHIR format, or restructuring CSV exports for clinician-facing visualizations. The conversion follows a fixed specification; software that converts based on analysis or judgment is not MDDS.
4. Electronic display of medical device data. Showing medical device data to clinicians, patients, or other users. For example, displaying a CGM trend graph on a smartphone screen or a clinician dashboard. Pure display, without analysis-driven alerts or treatment recommendations, qualifies as MDDS.
FDA’s MDDS definition is restrictive by design. The moment software analyzes data to make a clinical determination, drives another medical device, or provides clinically actionable alerts beyond a passive ‘data received’ notification, it leaves MDDS classification and enters SaMD territory. The line between transferring/storing/converting/displaying and analyzing is where most startup classification decisions get made.
Common MDDS Examples: Real-World Software That Qualifies
The clearest way to understand MDDS is to look at real products. The examples below describe software that performs purely data-transfer, storage, conversion, or display functions without analyzing the data to make medical decisions. Many of these products are part of larger systems that may also include SaMD components; the MDDS classification applies specifically to the data-handling portion.
Tidepool: diabetes data aggregation
Tidepool is an open-source platform that aggregates data from insulin pumps, CGMs, and blood glucose meters into a unified view for patients and clinicians. In its core data-aggregation function (pulling readings from devices, storing them, and displaying them in standardized formats), Tidepool operates as MDDS. The software transfers and stores medical device data without analyzing it to make treatment decisions. (Tidepool also offers Tidepool Loop, an automated insulin delivery system, which is separately FDA-cleared and is SaMD, not MDDS.)
Dexcom Clarity: CGM data reporting
Dexcom Clarity is the reporting platform that displays continuous glucose monitor data to patients and healthcare providers. Its core function (taking CGM readings from the device, storing them in the cloud, and presenting them as time-in-range reports and trend graphs) is MDDS territory. The platform displays data; it does not make treatment recommendations or drive the CGM. (The Dexcom CGM device itself, including the algorithm that converts sensor signal into glucose values, is a separately classified medical device, typically Class II.)
Patient portals (Epic MyChart and similar)
Patient-facing portals like Epic MyChart that display medical device data to patients, such as heart rate from a connected monitor, vitals from a remote patient monitoring kit, and lab results, fall within MDDS scope when their function is limited to receiving, storing, and displaying the data. The moment a patient portal adds clinically actionable alerts (e.g., ‘your blood pressure is dangerously high, contact your doctor immediately’), it crosses into SaMD because it’s now interpreting the data to drive clinical action.
Hospital data display and storage systems
Hospital-grade software that aggregates real-time data from connected medical devices such as vital-sign monitors, IV pumps, and ventilators, and displays it on a centralized clinician dashboard is MDDS when it functions as a pure data layer. The software collects data, stores it, and shows it to clinicians. If the system also generates clinical alarms based on threshold analysis, that alarming component is classified differently (often Class II), while the underlying data layer remains MDDS.
Format converters (HL7 to FHIR, CSV to FHIR, etc.)
Software that converts medical device data from one format to another according to a fixed specification qualifies as MDDS under the conversion function in 21 CFR 880.6310. An example is an integration layer that translates HL7 v2 messages from older medical devices into FHIR resources for modern clinical systems. The conversion follows a deterministic specification; the software does not interpret the data or make clinical judgments about it.
What Doesn’t Qualify as MDDS: When Software Crosses Into SaMD
The mistake startups most often make is assuming any software that handles medical device data is MDDS. The reality is narrower: software that analyzes, interprets, or acts on medical device data falls outside MDDS classification, even when transfer, storage, conversion, or display is also involved. The examples below show software commonly assumed to be MDDS, but that is actually Software as a Medical Device. Check the detailed FDA MDDS Guidance for better distinction.
Apple Watch ECG and Atrial Fibrillation detection
The Apple Watch’s ECG app and Irregular Rhythm Notification feature receive De Novo classification from the FDA as Class II Software as a Medical Device. The software does not just transfer or display heart rhythm data. It analyzes the rhythm and provides a clinical determination (possible atrial fibrillation). That analysis-to-determination function is precisely what disqualifies software from MDDS classification. (Apple Health as a general data aggregation platform may include MDDS-qualifying components, but the ECG and Afib detection features are SaMD.)
AI-based glucose prediction and pattern analysis
Software that takes CGM data and predicts future glucose values, flags hypoglycemia risk, or identifies patterns clinicians should act on is SaMD, not MDDS. The software is analyzing the data to produce a clinical insight that didn’t exist in the raw data. Even if the underlying data flow (sensor to phone to cloud) includes MDDS-qualifying transfer and storage functions, the prediction or pattern-analysis layer is SaMD and requires its own regulatory classification.
Clinical alert systems based on threshold analysis
Hospital software that monitors vital signs and generates clinical alerts (such as ‘patient’s blood pressure has dropped below the critical threshold; nursing team paged’) is not MDDS. The alarm-generation function is an analysis applied to medical device data, which places the alert system under SaMD or Class II classification. The data-collection-and-display layer underneath might still be MDDS, but the alert layer requires separate handling.
Closed-loop and hybrid closed-loop systems
Software that takes CGM data and uses it to drive insulin pump dosing, such as the algorithmic components of automated insulin delivery systems, is SaMD (and a combined controlled medical device). The software is not just transferring or storing data; it’s analyzing the data to control another medical device. Driving another device’s behavior falls completely outside MDDS scope, regardless of how the data was originally captured or stored.
Telehealth platforms with clinical decision support
Telehealth software that displays patient vitals to clinicians is potentially MDDS in its data-display function. But the moment the platform adds clinical decision support (recommending diagnoses, suggesting medication adjustments, flagging patients for follow-up based on data analysis), those features are SaMD and may require their own FDA clearance or alignment with the FDA’s Clinical Decision Support guidance.
How MDDS Went From Class III to Not a Device at All
Until 2011, MDDS was classified as Class III, the highest-risk FDA device category, requiring Premarket Approval (PMA) for market entry. In February 2011, the FDA issued a final rule reclassifying MDDS from Class III to Class I, recognizing that the risk profile of pure data-handling software did not warrant the regulatory burden of a PMA. In February 2015, FDA went further and issued guidance announcing enforcement discretion. Under this policy, the agency would not enforce regulatory controls on MDDS even though it remained technically a Class I device.
The structural change came with the 21st Century Cures Act, signed into law on December 13, 2016. Section 3060(a) of the Cures Act amended section 520 of the Federal Food, Drug, and Cosmetic Act to exclude certain software functions, including software that meets the MDDS criteria, from the statutory definition of a “device” under section 201(h). FDA’s September 2019 final guidance, titled “Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act,” formalized FDA’s interpretation: software-only MDDS functions are no longer FDA-regulated devices.
The current state introduces FDA’s terminology distinction: “Non-Device-MDDS” refers to software-only functions that meet MDDS criteria and are not regulated as a device under federal law. “Device-DDS” refers to hardware that performs the same functions and is still technically a Class I device under 21 CFR 880.6310, but is subject to FDA’s enforcement discretion. For a startup developing software-only platforms (cloud dashboards, mobile apps, integration layers) that meet the MDDS criteria, the practical effect is significant: no 510(k), no registration, no listing, no MDR, no design controls, and no quality system requirements that apply to FDA-regulated devices.
For a startup medical device company preparing for an IDE submission, the current FDA position on MDDS is the most consequential regulatory distinction within the classification system. Software that genuinely qualifies as Non-Device-MDDS does not enter the IDE-to-clearance pathway. The company can ship while focusing IDE submission preparation on components that are genuinely SaMD or other regulated device classes.
How to Determine If Your Software Is an MDDS
The classification decision is structured but requires honest assessment of what your software actually does, not just what marketing or product positioning describes it as doing. Walk through these five questions about your software’s actual function:
1. Does your software only transfer, store, convert, or display medical device data? If your software’s full functional scope is limited to these four data-handling activities defined in 21 CFR 880.6310, you are in MDDS territory. If your software does anything else, such as alarming based on threshold analysis, recommending clinical actions, controlling other medical devices, or generating diagnostic or prognostic outputs, you are likely outside MDDS scope.
2. Does your software analyze data to produce a clinical insight that didn’t exist in the raw data? Pattern analysis, anomaly detection, prediction, classification, and risk scoring are all examples. Any function that takes raw device data and produces new clinical output is a SaMD-style analysis, not an MDDS. The line is whether your software is reorganizing or presenting existing information (MDDS) or creating new information through analysis (SaMD).
3. Does your software control or drive another medical device? If your software sends commands to another medical device (such as adjusting an insulin pump’s basal rate, triggering a ventilator setting change, or modifying a pacemaker parameter), it is not MDDS. Driving other medical devices is one of the functions FDA explicitly disqualifies from MDDS classification.
4. Does your software generate clinical alerts or alarms beyond passive data-received notifications? A notification that says ‘new glucose reading received’ is passive and MDDS-compatible. A notification that says ‘glucose dropping rapidly, confirm patient status’ is an alert based on analysis and takes the software out of MDDS classification. The distinction is whether the notification is descriptive (data received) or prescriptive (action recommended).
5. Would a reasonable clinician rely on your software’s output for clinical decision-making? This is the implicit FDA test. If your software’s output is the kind of information a clinician would treat as authoritative for diagnostic, treatment, or management decisions, FDA likely considers it an SaMD, even if the developer doesn’t market it that way. MDDS outputs are reference information that supports clinician judgment without substituting for it.
If you answered ‘yes’ to question 1 only, your software likely qualifies as MDDS. Any ‘yes’ to questions 2 through 5 indicates SaMD or another regulated device class, with the corresponding FDA submission pathway. When the answer is genuinely ambiguous, particularly when software contains both MDDS-qualifying and SaMD-qualifying components, the safest approach is to request informal feedback through FDA’s Q-submission process or work with a regulatory specialist before committing to a regulatory strategy.
Why This Decision Matters Before You Submit Your IDE
For startup medical device companies preparing for IDE submission, the MDDS-vs-SaMD classification decision is one of the earliest regulatory decisions that compounds across the rest of the development timeline. Misclassifying SaMD as Non-Device-MDDS means proceeding without the V&V, design controls, and submission documentation FDA will eventually require. This creates remediation work that can extend timelines by 6 to 18 months when the misclassification surfaces during IDE review or premarket inspection.
Misclassifying MDDS as SaMD is less risky but more expensive: a startup that treats MDDS software genuinely as if it required a 510(k) submission spends months building documentation, generating performance data, and preparing a submission that the FDA may not require. For a startup with limited regulatory budget, that’s months of wasted regulatory consulting fees and engineering time.
Getting the classification right before IDE submission saves both failure modes. The classification work itself takes weeks, not months, and the savings on the wrong path are measured in calendar quarters of development time. For most startups, MDDS classification is the regulatory question with the highest leverage-to-effort ratio in the entire early-stage roadmap.
Frequently Asked Questions About MDDS Examples and Classification
What is an example of a Medical Device Data System (MDDS)?
Common MDDS examples include Tidepool’s diabetes data aggregation platform (its data-collection function), Dexcom Clarity’s CGM data reporting platform, patient portals that display medical device data without clinical alerts, hospital data-display dashboards that aggregate device readings, and software that converts medical device data between formats like HL7 to FHIR according to a fixed specification.
Is software MDDS still subject to FDA device regulation?
Generally no. Software-only MDDS functions are no longer FDA-regulated devices under current federal law. The 21st Century Cures Act of 2016 (Section 3060(a)) amended the FD&C Act to exclude software functions that meet the MDDS criteria from the statutory definition of a “device.” FDA’s September 2019 guidance formalized this position. Hardware MDDS components are still technically Class I devices under 21 CFR 880.6310 but subject to FDA enforcement discretion.
What is the difference between MDDS and SaMD?
MDDS only transfers, stores, converts, or displays medical device data without analyzing it. SaMD (Software as a Medical Device) analyzes data to produce clinical determinations, drive other medical devices, or recommend treatment actions. The moment software does anything beyond pure data handling (alerting based on analysis, predicting outcomes, controlling another device), it crosses from MDDS into SaMD classification.
Does MDDS require a 510(k) submission?
Generally no, and the answer is stronger than just “exempt.” Software-only MDDS functions are no longer devices under federal law, following the 21st Century Cures Act of 2016 and FDA’s September 2019 implementation guidance. That means 510(k), registration, listing, MDR, and quality system requirements that apply to FDA-regulated devices generally do not apply to Non-Device-MDDS. Hardware MDDS components are still technically devices but subject to FDA enforcement discretion.
What if my software is partly MDDS and partly SaMD?
Many real products contain both MDDS-qualifying and SaMD-qualifying functions. The classification applies function-by-function, not product-by-product. Software-only MDDS components (data transfer, storage, conversion, display) are not devices under federal law following the Cures Act; the SaMD components (analysis, alerting, decision support, device control) require their own regulatory classification and submission pathway. Clearly distinguishing the components is part of the IDE-stage strategy work.
How do I know if my software qualifies as MDDS for FDA purposes?
Apply the four functions defined in 21 CFR 880.6310 (transfer, storage, conversion, display) to your software’s actual behavior. If your software performs only those functions and does not analyze data, drive other devices, or generate clinical alerts based on analysis, it likely qualifies as MDDS. When the answer is ambiguous, request informal feedback via FDA’s Q-submission process or consult a regulatory specialist before finalizing your regulatory strategy.
Get the Classification Right Before Your IDE Submission
MDDS or SaMD is the regulatory fork that compounds across the rest of your startup’s development timeline. Sequenex helps medical device startups walk through the classification framework before significant engineering investment, so the IDE submission strategy starts on the right path.
This article describes Medical Device Data System (MDDS) classification under FDA 21 CFR 880.6310 and the 21st Century Cures Act of 2016 for informational purposes only and is not legal or regulatory advice. Regulatory classification decisions depend on the specific facts of each product and may involve nuanced application of FDA guidance. Companies preparing for FDA submission should consult qualified regulatory professionals before finalizing classification strategy.
