Medical Device Data Systems (MDDS): FDA Definition & Regulations

Medical Device Data Systems

Medical Device Data Systems (MDDS): FDA Definition, Classification & Requirements

Medical Device Data Systems (MDDS)

Medical Device Data Systems (MDDS) are the products that move medical device data from one place to another without changing it. They connect bedside devices to hospital records, archive readings for later review, and convert data into readable formats. Because they only carry and present data, the FDA has long treated them as low risk.

How MDDS is regulated has changed over time. Software MDDS functions are now outside the FDA's device definition, while hardware MDDS is still a defined device type that the FDA does not actively regulate. This guide explains the definition, how to tell a device MDDS from a non-device MDDS, how MDDS differs from Software as a Medical Device (SaMD), and what to consider before you build or sell one.

MDDS Definition by the FDA:

The FDA defines an MDDS as a hardware or software product intended to transfer, store, convert formats, and display medical device data. An MDDS does not modify the data or the way the data is displayed, and it does not by itself control the functions or parameters of any other medical device. It also does not include devices used for active patient monitoring, meaning devices that clinicians rely on to decide on immediate clinical action.

An MDDS performs one or more of four functions, without altering what it handles:

Electronic transfer of medical device data
Electronic storage of medical device data
Electronic conversion of medical device data from one format to another, in line with a preset specification
Electronic display of medical device data

The MDDS regulation is 21 CFR 880.6310. Under medical device classification, MDDS is Class I (general controls) and exempt from 510(k) premarket notification, subject to certain limitations. Hardware for an MDDS may include physical communication media, modems, and interfaces.

Identification of Non Device MDDS and Device MDDS as per FDA Regulations

Since the 21st Century Cures Act of 2016, the FDA splits MDDS into two groups:

Non-Device MDDS: software functions that only transfer, store, convert, or display device data. They are not devices under the FD&C Act.
Device MDDS: hardware functions that do the same. They remain a defined device type, but the FDA does not intend to enforce regulatory controls for them.

The key test in both groups is the word "solely." Once a function analyzes, interprets, or alters data, it falls outside MDDS.

Non-Device MDDS:

Criteria	Classification	Regulatory requirements	Example
Software functions that meet the definition of Non-Device MDDS, medical image storage, or medical image communications	Non-Device MDDS	Not subject to FDA premarket review	Storing patient data, such as blood pressure readings, for later review
Software functions solely intended to transfer, store, convert formats, or display medical device data and results (including images, waveforms, signals, or other clinical information)	Non-Device MDDS	Not subject to FDA premarket review	Converting digital data from a pulse oximeter into a format that can be printed
Software functions that analyze or interpret medical device data, in addition to transferring, storing, converting, or displaying it	Not a Non-Device MDDS	Subject to FDA regulatory oversight	Displaying a stored electrocardiogram and automatically detecting issues

Device MDDS:

Criteria	Classification	Regulatory requirements	Example
Hardware functions intended to transfer, store, convert formats, or display medical device data and results	Device MDDS	Class I, exempt from premarket notification; the FDA does not intend to enforce regulatory controls	A dedicated medical data storage server that archives data from ECG machines and blood glucose monitors without modifying it, so providers can retrieve and review it
Hardware functions limited to assisting the software functions of transfer, storage, conversion, or display, and that do not modify the data or control connected devices	Device MDDS	Same as above	A communicator that integrates with ECG devices and passes the data to another location without altering it
An in vitro device for assessing cardiovascular disease risk or for diabetes management, or hardware whose firmware processes and analyzes the signal	Not a Device MDDS	Subject to FDA regulatory oversight	Hardware with firmware that processes and analyzes a signal, which must meet the relevant FDA requirements

MDDS vs SaMD: What Is the Difference?

MDDS and Software as a Medical Device (SaMD) can look alike, since both are software handling health data. The difference is what the software does with the data. An MDDS moves and presents data unchanged. SaMD is software with a medical purpose that performs that purpose on its own, for example by analyzing data to diagnose, monitor, or guide treatment.

	MDDS (non-device)	SaMD
Main job	Transfer, store, convert format, display	Analyze, interpret, diagnose, monitor, or inform treatment
Data handling	Leaves data and display unchanged	Processes data to produce clinical output
Risk	Low	Low to high, depending on the use
FDA status	Not a device	Regulated device

Function and Intended Use

An MDDS is defined by what it is intended not to do: it does not interpret, alter, or act on the data. SaMD is defined by a medical purpose, such as detecting a condition, calculating a clinical value, or recommending an action. Your intended use statement, labeling, and marketing claims decide which side you are on. Wording such as "alerts clinicians to abnormal readings" moves a product from MDDS toward SaMD.

Risk and Impact

MDDS carries low risk, though not zero. Inaccurate, incomplete, or delayed data could contribute to a wrong clinical decision, so data integrity still matters. SaMD can influence diagnosis and treatment directly, so its risk depends on the seriousness of the condition and how much the output drives care. This is why SaMD needs formal risk management under ISO 14971 and life cycle controls under IEC 62304.

FDA Regulatory Classification

Non-Device MDDS software is not a device, so it has no medical device classification and no premarket requirements. SaMD is a device and is classified by risk: Class I, II, or III. Depending on the class, it goes through an FDA 510(k), De Novo, or premarket approval (PMA). Its premarket submission includes software documentation at the Basic or Enhanced level, and the developer follows a quality system under 21 CFR Part 820 (now the QMSR, based on ISO 13485).

Key Regulatory Considerations for MDDS

Intended use decides everything. Keep the intended use statement and all labeling and marketing consistent with "solely" transferring, storing, converting, or displaying data.
Know where the line is. Adding analysis, interpretation, thresholds, alarms, or data modification can turn an MDDS into a regulated device. Reassess whenever you add a feature.
Watch for active patient monitoring. Products used to monitor patients where clinicians act immediately on the data are not MDDS.
Document your determination. Keep a short record of why your product qualifies as MDDS, including the functions it does and does not perform.
Check hardware limits. Device MDDS hardware is Class I and exempt from 510(k) with limitations set out in 21 CFR 880.9. The FDA does not intend to enforce regulatory controls for it, but the limitations are worth checking for your product.
Watch multi-function products. If your product includes both MDDS and regulated device functions, the regulated functions are subject to FDA requirements, and the FDA may consider how the other functions affect them.
Ask when unsure. A Pre-Submission or a 513(g) request can clarify whether your product is a device and how it would be classified.
Use good practice even when not required. Many hospital customers expect a quality system based on ISO 13485, software life cycle practices from IEC 62304, and risk management based on ISO 14971. These help demonstrate data integrity and reliability.
Design the display carefully. If your product displays data to clinicians, poor presentation can cause misreading. Usability engineering, including formative and summative evaluation, helps catch use errors early.
Address cybersecurity and privacy. Connected products need security controls, and health data brings privacy obligations. The FDA's cybersecurity requirements apply if the product is, or is part of, a regulated device.
Confirm identification obligations. If any part of your product is a regulated device, labeler duties such as UDI and GUDID submissions may apply. Confirm the position for each product with the FDA.
Plan for other markets. In the EU, whether software is a medical device depends on its intended purpose under the MDR. If it is, a clinical evaluation report (CER) and other technical documentation are needed.

What is Not an MDDS?

General-purpose IT infrastructure in healthcare facilities is not an MDDS. This holds when it stays within its original manufactured specifications, and modifications within its predefined operating parameters still count as general IT infrastructure. Components doing the functions below are not MDDS when used as part of general IT infrastructure, even if they transfer, store, display, or convert medical device data alongside other information.

Function	Examples
Electronic transfer of medical device data	Network router, network hub, wireless access point
Electronic storage of medical device data	Network attached storage (NAS), storage area network (SAN)
Electronic conversion of medical device data from one format to another, in line with a preset specification	Virtualization system (such as VMware), PDF software
Electronic display of medical device data	Computer monitor, large-screen display

The difference from a true MDDS is purpose. A general-purpose router or monitor is not built or labeled for medical device data. A product designed and sold specifically to move or store medical device data may be an MDDS.

Frequently Asked Questions About Medical Device Data Systems

1. Is MDDS still regulated by the FDA?

Mostly not. Software MDDS functions are no longer devices under the FD&C Act, thanks to the 21st Century Cures Act, so they are not regulated as devices. Hardware MDDS is still a defined Class I device type under 21 CFR 880.6310. The FDA has said it does not intend to enforce the regulatory controls for it, including registration and listing, premarket review, postmarket reporting, and quality system requirements.

Any function that goes beyond MDDS, such as analyzing or interpreting data, is regulated as a device. So is any part of a multi-function product that meets the device definition.

2. Does MDDS require FDA clearance or approval?

No. Non-Device MDDS software is not subject to premarket review, so it needs neither an FDA 510(k) nor premarket approval. Hardware MDDS is exempt from 510(k) and is not enforced against. If your product analyzes or interprets data, or is otherwise a device, it needs premarket authorization according to its medical device classification and risk. Depending on the case, that means a 510(k), De Novo, or PMA.

3. What types of software qualify as MDDS?

Software functions solely intended to transfer, store, convert formats, or display medical device data and results, including images, waveforms, signals, and other clinical information. Typical examples are software that archives blood pressure readings for later review, converts pulse oximeter data to a printable format, or passes device data to a central record. To qualify, the software must not modify the data or its display, must not control other devices, and must not analyze or interpret the data. It also cannot be used for active patient monitoring.

4. Can MDDS software be considered SaMD?

Generally not. Non-Device MDDS software is not a device, so it is not regulated SaMD. But a product can combine MDDS functions with functions that analyze or interpret data. Those analytical functions are SaMD or device software functions, and they must meet FDA requirements. That includes risk management under ISO 14971, IEC 62304 development practices, software documentation for the submission, and, where applicable, usability engineering evidence such as summative evaluation. The MDDS-type functions in the same product remain non-device.