FDA MDDS Guidance: The Current FDA Position on Medical Device Data Systems

For startup medical device teams preparing for IDE submission, knowing the current state is the difference between accurate regulatory planning and wasted submission work.

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. For startup medical device companies, the practical effect is significant: software that meets the MDDS criteria can ship without the 510(k) submission, registration, listing, or post-market reporting requirements that apply to FDA-regulated devices.

The Five Milestones in FDA’s MDDS Guidance

FDA’s position on Medical Device Data Systems didn’t change overnight. It evolved through five distinct regulatory milestones across nearly a decade, each loosening the regulatory burden on software-only MDDS until the Cures Act removed it from device regulation entirely. Walking through this timeline matters because residual confusion about the prior framework “isn’t MDDS a Class I device?” still drives misunderstandings about what the current FDA position actually requires.

Milestone 1 — February 15, 2011: MDDS reclassified from Class III to Class I

FDA’s first MDDS rule was the February 15, 2011 final rule that down-classified Medical Device Data Systems from Class III (the highest-risk device category, requiring Premarket Approval) to Class I (the lowest-risk category, subject only to general controls). The rule was codified at 21 CFR 880.6310 and defined MDDS narrowly as software intended to transfer, store, convert, or display medical device data without analyzing or interpreting it. The 2011 rule recognized that pure data-handling software did not pose risks sufficient to justify Class III review. This reclassification was the foundation for everything that followed.

Milestone 2 — February 9, 2015: FDA announces enforcement discretion

Four years after reclassification, FDA issued final guidance titled “Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices.” The 2015 guidance announced that FDA does not intend to enforce compliance with the regulatory controls that apply to MDDS, including Medical Image Storage Devices (MISD) and Medical Image Communications Devices (MICD). In practice, this meant MDDS was still technically a Class I device under 21 CFR 880.6310, but the FDA would not enforce 510(k), registration, listing, or post-market requirements against it. The 2015 guidance applied this enforcement discretion to both software-only MDDS and hardware MDDS.

Milestone 3 — December 13, 2016: 21st Century Cures Act Section 3060(a)

The 21st Century Cures Act, signed into law on December 13, 2016, was the structural change. Section 3060(a) of the Cures Act amended section 520 of the Federal Food, Drug, and Cosmetic Act to add subsection (o), which removed certain software functions from the statutory definition of a “device” in section 201(h). Five categories of software functions were excluded: administrative support of healthcare facilities, encouragement of healthy lifestyles, electronic patient records, transfer/storage/conversion/display of medical device data (the MDDS criteria), and limited clinical decision support. The fourth category, transfer/storage/conversion/display, codified the MDDS exclusion at the statutory level, making it more than just regulatory enforcement policy.

Milestone 4 — September 27, 2019: FDA’s implementation of Section 3060

Nearly three years after the Cures Act, FDA issued final guidance interpreting Section 3060’s impact on its regulatory framework. The guidance, titled “Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act,” formalized FDA’s position that software functions meeting the MDDS criteria are no longer FDA-regulated devices. FDA simultaneously issued conforming revisions to four existing guidance documents, including the 2015 MDDS guidance, to align them with the Cures Act’s statutory changes. The September 2019 guidance also introduced the distinction between “Non-Device-MDDS” (software-only functions, no longer a device) and “Device-DDS” (hardware functions, still technically a device but subject to enforcement discretion).

Milestone 5 — September 28, 2022: Minor consistency update

The most recent FDA update on MDDS was a September 28, 2022, minor update to the original 2015 guidance document, made to ensure consistency with FDA’s broader medical software framework. The 2022 update did not change FDA’s substantive position on MDDS; it aligned terminology and cross-references with the agency’s other software guidance documents updated around the same period. The current state of FDA’s MDDS guidance, as of mid-2026, remains as articulated in the September 2019 implementation guidance and the September 2022 consistency update.

Non-Device-MDDS vs. Device-DDS: The Distinction That Determines Your Regulatory Burden

The September 2019 FDA guidance introduced a distinction that startup medical device companies need to understand: the difference between Non-Device-MDDS and Device-DDS. The names are not intuitive, but the regulatory implications are significant: one category is essentially free from FDA device regulation; the other is technically still a device but subject to enforcement discretion.

The practical difference matters for startups deciding whether to bundle their MDDS-handling functions into a software-only product or into the hardware they’re manufacturing. Pure software platforms, cloud dashboards, mobile apps, integration layers, that meet the MDDS criteria are in the strongest position under current FDA guidance: not a device at all. Hardware products that also perform MDDS functions, such as connected vital-sign monitors, gateway devices, and hospital data hubs, remain technically devices, even if the specific MDDS-handling portions of their functionality are not currently enforced.

Who FDA’s Current MDDS Guidance Applies To

FDA’s MDDS guidance has the broadest reach for startup medical device companies developing software that handles data from medical devices, but the criteria are specific. Software that goes beyond data handling moves out of MDDS classification and into Software as a Medical Device (SaMD) territory, where the FDA’s regulatory framework fully applies. The audiences below are the ones most directly affected by the current MDDS guidance in regulatory strategy.

Connected device companies building data infrastructure

Startups developing connected medical device platforms, cloud infrastructure, data pipelines, and integration layers that handle data from FDA-regulated medical devices typically have substantial MDDS-qualifying functionality at the platform layer. The data ingestion, storage, format conversion, and dashboard display components meet the MDDS criteria. Under current FDA guidance, these functions can be built and shipped without the device regulation burden, even when they’re integrated with hardware that is itself FDA-regulated.

Biosensor and wearables software platforms

Startups in the biosensor and wearables space typically have a software layer that aggregates sensor data, displays it to users and clinicians, and integrates with other platforms, all of which qualifies as Non-Device-MDDS functionality. The sensor itself and any analysis algorithms are separately regulated (typically as SaMD or Class II devices), but the data-handling layer can be built under MDDS-style assumptions.

Continuous glucose monitor (CGM) data platforms

CGM data platforms, patient-facing apps, clinician dashboards, and data aggregation services typically include substantial MDDS-qualifying functionality. The CGM sensor and its core algorithm are FDA-regulated devices; the platform that receives, stores, and displays the resulting glucose data is generally Non-Device-MDDS under current FDA guidance. This is the regulatory framework that products like Dexcom Clarity operate under.

Hospital data and EHR integration platforms

Software that aggregates data from connected medical devices in clinical settings, such as vital sign monitors, IV pumps, and ventilators, and displays it on clinician dashboards or pushes it into electronic health records is largely Non-Device-MDDS. The medical devices themselves are FDA-regulated; the data layer that handles their output, transmits, stores, and displays it without analyzing it is not a device under current FDA guidance.

Common Misinterpretations of FDA’s Current MDDS Guidance

The MDDS regulatory framework has evolved to the point that residual confusion is widespread. Startup teams encounter outdated information from older blog posts, regulatory consultants quoting pre-Cures Act framing, and FDA’s own 21 CFR 880.6310 regulation, which is still technically on the books but functionally superseded for software. Four misinterpretations come up most often:

Misinterpretation 1 — “MDDS is Class I, so you still need to register and list”

This was true between 2011 and 2016: MDDS was Class I, manufacturers were technically required to register their establishment, list devices, and maintain MDR processes. After the Cures Act amended section 520 of the FD&C Act in December 2016, software-only MDDS is no longer a device under federal law. Registration, listing, and MDR requirements that apply to FDA-regulated devices do not apply to Non-Device-MDDS. The 21 CFR 880.6310 regulation is still in the books, but the statutory change in 520(o) supersedes it for software.

Misinterpretation 2 — “Active patient monitoring software is just MDDS”

This is the most consequential misinterpretation. Software marketed for “real-time” or “active” patient monitoring, in which clinicians rely on the software for ongoing patient surveillance, often with implicit or explicit treatment-decision implications, has been a particular area of FDA concern, even after the Cures Act. Active monitoring functionality typically involves analysis, threshold-based alerting, or implicit clinical interpretation, all of which take the software out of MDDS scope and into SaMD territory. FDA has cleared numerous patient monitoring software products through 510(k); marketing your software for “active monitoring” while claiming MDDS exclusion is the kind of mismatch FDA scrutinizes.

Misinterpretation 3 — “Any software touching medical device data is MDDS”

MDDS is defined by the four specific functions in the regulation: transfer, store, convert, display. Software that analyzes the data, generates clinical insights, drives other medical devices, or provides alarms based on threshold analysis is not MDDS; it’s SaMD or another regulated device class, regardless of whether transfer/storage/conversion/display functions are also present. Many real products contain both MDDS and non-MDDS functions; the classification applies function-by-function, not product-by-product.

Misinterpretation 4 — “FDA’s MDDS guidance means we don’t need a quality system”

Software that is Non-Device-MDDS is not subject to FDA’s Quality System Regulation (21 CFR 820 / 21 CFR 4) because it’s not a device. But startup medical device companies typically have device hardware, SaMD components, or other regulated products in their portfolios, and the quality system must cover them. Operating a quality system that covers your regulated functions while excluding your Non-Device-MDDS functions is appropriate. Operating without a quality system at all because “we’re just MDDS” is a mistake that creates audit risk for the regulated components of your business.

What FDA’s Current MDDS Guidance Means for Startups Preparing for IDE Submission

For startup medical device companies preparing for Investigational Device Exemption (IDE) submission, the current FDA MDDS guidance affects scope decisions made early in development. The data-handling components of your product platform, cloud infrastructure, dashboards, integration layers, and format conversion typically qualify as Non-Device-MDDS and do not need to be included in the IDE submission package. This narrows the regulatory scope of the IDE to the actual investigational device and its directly-associated software functions, rather than expanding it to cover the entire connected device platform.

Getting this scoping decision right at the start of IDE preparation matters because over-scoping creates downstream burden. A startup that treats its entire software platform as in scope for IDE, including the Non-Device-MDDS layers, ends up with V&V documentation, design controls, and risk management activities applied to software that doesn’t require them. That’s months of regulatory work that could have been avoided with accurate scoping. Under-scoping is also a risk, but a smaller one: if FDA identifies in-scope software that wasn’t documented, the IDE submission can be amended. Over-scoping work is rarely recovered.

The IDE-stage decision points where FDA’s MDDS guidance matters most: defining your Investigational Device, defining the Software Description for your IDE submission, scoping your V&V plan, scoping your risk management file, and writing the regulatory strategy section of your investigational plan. Each of these requires you to articulate what software is and isn’t part of the investigational device. The Non-Device-MDDS distinction provides a structured way to make that articulation defensible to FDA reviewers.

Frequently Asked Questions About FDA MDDS Guidance

What is FDA’s current guidance on Medical Device Data Systems (MDDS)?

FDA’s current MDDS guidance is articulated through two key documents: the 2015 final guidance “Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices” (with minor updates in 2019 and 2022) and the September 2019 final guidance “Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act.” Together they establish that software-only MDDS functions are not FDA-regulated devices under current federal law.

Did the 21st Century Cures Act remove MDDS from FDA regulation?

Largely yes for software-only MDDS. Section 3060(a) of the 21st Century Cures Act, enacted on December 13, 2016, amended section 520 of the Federal Food, Drug, and Cosmetic Act to remove certain software functions, including software that meets the MDDS criteria, from the statutory definition of a device under section 201(h). Hardware MDDS components are still technically devices, but FDA exercises enforcement discretion.

Do I need to register my company with FDA if my software is MDDS?

For software-only MDDS functions, generally no. Non-Device-MDDS is not a device under federal law after the Cures Act, so device registration and listing requirements do not apply. However, if your company makes any FDA-regulated devices alongside your MDDS software (hardware devices, SaMD products, combination products), you still need to register and list those regulated products. Many startups have a mix of regulated and non-regulated products.

Is FDA’s MDDS guidance the same as the MDDS regulation at 21 CFR 880.6310?

Not anymore; they conflict in practice. 21 CFR 880.6310 still classifies MDDS as a Class I device, but the 21st Century Cures Act removed software MDDS from the statutory definition of a device. FDA’s current guidance reflects the Cures Act change; the underlying regulation is technically still in the books but functionally superseded for software. The guidance is what applies in practice.

Does FDA’s MDDS guidance apply to active patient monitoring software?

Generally no. Active or real-time patient monitoring typically involves analysis, threshold-based alerting, or clinical interpretation, functions that take software out of MDDS scope and into the territory of Software as a Medical Device (SaMD). FDA has historically scrutinized software marketed for active monitoring even when companies claim MDDS exclusion. The MDDS guidance applies to passive data handling: transfer, storage, conversion, display, without analysis-driven outputs.

How does FDA’s MDDS guidance affect IDE submission for a connected medical device startup?

The MDDS guidance narrows the scope of what needs to be included in your IDE submission. Data-handling components of your platform, cloud infrastructure, dashboards, integration layers — that meet the Non-Device-MDDS criteria typically do not need to be included in the IDE Software Description, V&V plan, or risk management file. This focuses the IDE on the actual investigational device and its directly associated software, rather than on the entire connected platform.

Get the FDA MDDS Guidance Right Before You Plan Your IDE

FDA’s MDDS guidance has evolved to the point where residual confusion is the norm rather than the exception. Sequenex helps medical device startups navigate the current FDA position, accurately scope their IDE submissions, and avoid regulatory over-scoping that can cost months of unnecessary documentation work.

This article describes FDA’s guidance on Medical Device Data Systems (MDDS) under current federal law, including the 21st Century Cures Act of 2016, for informational purposes only and is not legal or regulatory advice. FDA’s guidance documents are non-binding statements of agency policy and may evolve; current FDA positions should be verified against the most recent guidance documents at fda.gov. Companies preparing for FDA submission should consult qualified regulatory professionals before finalizing classification or submission strategy.