The Startup MDVisit Website →
← Back to blog

MDDS and FDA: 6 Steps U.S. Healthtech Teams Use to Avoid 510(k)

September 17, 2026
MDDS and FDA: 6 Steps U.S. Healthtech Teams Use to Avoid 510(k)

Under U.S. law, MDDS covers only systems that transfer, store, convert, or display medical device data without interpreting it. The FDA generally treats these functions as low risk and does not intend to enforce most device requirements against them, but that relief is conditional on intended use. If your product adds analysis, alarms, or control features, confirm your intended-use statement now and document exactly where your MDDS boundary sits.

TL;DR:

  • Software-only products that transfer, store, convert, or display data are generally treated as non-regulated activities unless they add analysis, alarms, or control functions.
  • Adding interpretive, alarm, or device-control features can trigger the need for 510(k) clearance and regulatory oversight, even if the core function remains passive.
  • Maintaining explicit, written intended-use statements and risk management documentation is essential for ongoing compliance and clear regulatory boundaries.
  • A product that modifies clinical data values, controls other devices, or actively monitors patients no longer qualifies as an MDDS under FDA rules.
  • Industry guidance emphasizes applying software best practices and building compliance into design from the start to avoid costly rework and facilitate faster product approvals.
The StartupMD
Navigate Your Healthtech Growth Challenges
The StartUp MD brings healthcare and technology expertise to startups navigating product-market fit, fundraising, and growth challenges.
Explore The StartUp MD

Table of Contents

What Does the FDA Actually Define as an MDDS?

The legal definition lives in 21 CFR §880.6310, which classifies MDDS as Class I devices subject to general controls. The regulation names four functions, and a product only qualifies as an MDDS if it stays inside them.

  • Transfer: moving data electronically from one system to another, such as a bedside monitor feed routing into an EHR.
  • Store: holding medical device data for later retrieval, like a cloud archive of lab results.
  • Convert: changing data format to a preset specification without altering clinical content, for example reformatting HL7 messages for a dashboard.
  • Display: presenting data for viewing, such as a tablet app showing vital-sign trends generated elsewhere.

The FDA's own MDDS page is explicit about what falls outside this scope. An MDDS cannot modify the underlying data or control the function of another medical device. That excludes hardware or software built for active patient monitoring, along with anything that generates alarms or adjusts a connected device's settings. The moment your product crosses from passive handling into interpretation or control, it is no longer operating as an MDDS.

Device-MDDS vs. Non-Device-MDDS: Why Software Gets Treated Differently

Not every MDDS sits in the same regulatory bucket. The distinction between hardware and software versions explains why two products doing similar work can face different oversight.

  • Device-MDDS covers hardware that performs transfer, storage, conversion, or display. It technically remains a device under the CFR, but the FDA's enforcement discretion still applies to most of it.
  • Non-Device-MDDS covers software-only versions of those same functions. Following the 21st Century Cures Act, many of these functions no longer meet the legal definition of a device at all.
  • Software as a Medical Device (SaMD) diverges once a function adds analysis, interpretation, alarm generation, or control over another device. Those triggers push a product out of MDDS territory and into active device regulation, regardless of how the vendor markets it.

The functional trigger, not the delivery format, decides classification. A cloud dashboard that only displays numbers stays a Non-Device-MDDS. The same dashboard flagging abnormal trends for clinical action becomes something else entirely.

How Did We Get Here? A Short Regulatory Timeline

  1. 2011: The Federal Register final rule reclassified MDDS from Class III to Class I, exempting most from premarket notification and explaining the agency's low-risk rationale for pure data-handling functions.
  2. 2016: The 21st Century Cures Act amended section 520(o)(1)(D) of the Food, Drug, and Cosmetic Act, narrowing which software functions count as devices and formally excluding many transfer, storage, and display functions from that definition.
  3. 2015 and 2022: FDA guidance updates, most recently the 2022 guidance on MDDS, medical image storage, and image communications devices, confirmed the agency does not intend to enforce device requirements for many MDDS functions under section 201(h).

Each step narrowed the regulatory footprint further, but none of them eliminated it. The 2022 guidance still frames this as enforcement discretion, not a permanent exemption.

What Manufacturers Still Have to Do

Enforcement discretion is an administrative choice, not a statute. The FDA can revisit it if an MDDS or an integrated function introduces unexpected risk, particularly in multiple-function products where non-device features interact with regulated device functions. That reality shapes what actually belongs on a compliance checklist.

  • Write and keep an explicit intended-use statement that names the exact functions your product performs, leveraging expert Healthcare IT Services & HIPAA Compliance to ensure your system architecture meets regulatory and security standards.
  • Maintain a risk management file even if design controls are not legally required for your current classification.
  • Adopt relevant design controls and traceability documentation, since inspection-readiness matters more than technical exemption status.
  • Watch for feature creep. Adding analytics, alerts, or device-control capability can trigger 510(k) requirements or new registration and listing obligations.
  • Track how MDDS functions affect the safety of any connected regulated device, since FDA can evaluate the whole system rather than isolated modules.

Industry analysis of the 2022 guidance reinforces that manufacturers should keep applying software best practices even when a function sits outside active enforcement. Teams that skip this step often find themselves scrambling once a product roadmap adds the analytic feature that changes everything.

Pro Tip: Build your risk management file before your first customer contract, not after your first audit request. Investors and enterprise buyers increasingly ask for it during diligence, and retrofitting documentation under deadline pressure is where most startups stumble.

A Checklist: Does Your Product Qualify as an MDDS?

  1. Does your product only transfer, store, convert, or display data? If yes, continue. If it interprets or analyzes data, it likely falls outside MDDS scope.
  2. Does it alter the underlying medical device data in any way? Reformatting for display is fine; changing clinical values is not.
  3. Does it control or adjust the function of another medical device? Any control function removes MDDS eligibility.
  4. Is it intended for active patient monitoring? Active monitoring hardware is explicitly excluded from the MDDS definition.
  5. Have you documented your intended-use statement and design boundaries in writing? Labels, product descriptions, and internal specs should all agree.
  6. Are you seeing any borderline signals like customer requests for alarms, thresholds, or automated recommendations? Treat these as red flags and loop in regulatory counsel or an experienced advisor before shipping the feature.

Document each answer. A one-page intended-use memo, reviewed whenever you add a feature, is often the single most effective control a small healthtech team can maintain.

Practical Compliance Priorities From Paul Bergeron, MD, MBA

Startups tend to treat MDDS classification as a one-time legal question rather than an ongoing product decision. The better approach is to separate MDDS functions from anything analytic or diagnostic at the architecture level, not just in a policy document. Build minimal, auditable design controls and risk documentation while the codebase is still small. Once a product adds alarms, thresholds, or interpretive output, bring in a fractional CMO or regulatory advisor before launch, not after a customer or investor asks the hard question first.

Illustration of MDDS function separation

Why Treating MDDS Compliance as Strategic Product Work Pays Off

Regulatory clarity is a sales asset, not just a legal one. Enterprise health systems and investors both probe intended-use boundaries during diligence, and a team that can explain its MDDS scope in one paragraph moves faster through procurement than one that improvises an answer. Designing functional boundaries on purpose, rather than discovering them during an audit, also preserves your option to add regulated features later without rebuilding the product from scratch.

— Paul Bergeron MD, MBA

How The StartUp MD Helps Healthtech Teams Navigate MDDS Decisions

Healthtech founders benefit from direct access to physician-level regulatory judgment rather than generic compliance advice. That combination of clinical and business expertise means fewer wasted engineering cycles chasing features that would trigger 510(k) review before you're ready for it.

The StartupMD

If your product sits near the line between Non-Device-MDDS and SaMD, that ambiguity is exactly where founders lose months to rework. The StartupMD's Advisory Services and Fractional Chief Medical Officer engagements help teams pressure-test intended-use statements, prepare QMS documentation for investor diligence, and separate MDDS functions from analytic ones at the architecture stage. For teams also building design control documentation, pairing that work with resources like the design controls overview for SaMD or a QMSR readiness checklist shortens the path to an audit-ready file. Reach out before your next funding round or your next feature launch, whichever comes first, and bring your intended-use statement to the conversation.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Sources

FAQ

What Is the FDA's Definition of an MDDS?

An MDDS is hardware or software intended solely to transfer, store, convert to a preset format, or display medical device data, without modifying the data or controlling another device's function, per 21 CFR §880.6310.

What Is the FDA's Current Guidance on MDDS Enforcement?

The FDA's 2022 guidance states that many MDDS software functions are not devices under section 201(h), and the agency does not intend to enforce device requirements against them as long as they stay within transfer, storage, conversion, or display.

Does an MDDS Need FDA Clearance or a 510(k)?

Most MDDS functions are exempt from premarket notification under the 2011 reclassification to Class I, but a 510(k) can become necessary if you add analytic, alarm, or control features that push the product into active device regulation.

Are There New FDA Rules for MDDS in 2026?

There is no new MDDS-specific rule issued recently. The governing framework remains the 2011 Federal Register reclassification, the Cures Act amendments, and the 2022 guidance, so current compliance work centers on applying that existing framework carefully as products add features.

What Are Some Examples of FDA-Regulated Devices Near the MDDS Line?

Bedside monitors, infusion pumps, and diagnostic imaging equipment are FDA-regulated devices in their own right; an MDDS that only displays their output stays exempt, but a dashboard that also generates clinical alerts from that same data crosses into SaMD territory.