FDA Medical Device Data Systems (MDDS): 21 CFR § 880.6310, Cures Act § 520(o)(1)(D), Mobile Medical Apps, and General Wellness Rules

A Medical Device Data System (MDDS) is a digital health technology—either software or specialized hardware—intended solely to provide the electronic transfer, storage, format conversion (according to preset specifications), or display of medical device data, without controlling or altering the functions or parameters of any connected medical device and without being intended for active, time-critical patient monitoring. Regulated historically under 21 CFR § 880.6310 and restructured by Section 3060 of the 21st Century Cures Act (FD&C Act § 520(o)(1)(D), 21 U.S.C. § 360j(o)(1)(D)), the MDDS framework sits at the center of the U.S. Food and Drug Administration’s (FDA) digital health regulatory boundary.

For biomedical engineers, health IT architects, and clinical trial sponsors building telemetry middleware, remote patient monitoring (RPM) ingestion hubs, or mobile health apps, determining whether a software module is a Non-Device-MDDS, a low-risk General Wellness product, a mobile app under FDA enforcement discretion, or a regulated Software as a Medical Device (SaMD) determines whether the product is exempt from FDA regulation or must comply with 510(k)/De Novo/FDA Premarket Approval (PMA) submissions, ISO 14971 / ISO/TR 24971 risk management, and Unique Device Identification (UDI) labeling.

The Four Statutory MDDS Functions and the Cures Act Split

In its September 2022 final guidance, Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices, the FDA aligned its regulatory policy with Section 3060 of the 21st Century Cures Act. A product performs an MDDS function when it executes one or more of four strictly passive data operations on medical device data:

1. Electronic Transfer: Transmitting medical device data from a medical device (such as a bedside infusion pump, ventilator, or Bluetooth blood pressure cuff) to an EHR, clinical data repository, or middleware server without modifying the clinical content.
2. Electronic Storage: Archiving historical medical device data or waveforms in a database or cloud repository for later retrieval and review.
3. Electronic Format Conversion: Translating medical device data from one syntax or communication protocol to another according to preset specifications (for example, converting proprietary RS-232 serial device output into IEEE 11073, HL7 v2 ORU^R01, or HL7 FHIR R4 Observation JSON).
4. Electronic Display: Rendering stored or transferred medical device data on a workstation, tablet, or smartphone screen solely for retrospective or non-time-critical review.

Non-Device-MDDS (Software) vs. Device-MDDS (Hardware)

Following the 21st Century Cures Act, the FDA distinguishes between software functions and specialized hardware products performing MDDS operations:

Category	Statutory / CFR Citation	Scope of Products Included	FDA Regulatory Status
Non-Device-MDDS (Software Functions)	FD&C Act § 520(o)(1)(D) (21 U.S.C. § 360j(o)(1)(D))	Software applications, APIs, cloud middleware, and mobile apps intended solely to transfer, store, convert formats, or display medical device data or medical imaging data (including 21 CFR § 892.2010 / § 892.2020 software functions)	Not a medical device by statute; completely excluded from FDA device registration, listing, 510(k), QMSR (21 CFR Part 820), MDR (Part 803), and UDI
Device-MDDS (Hardware Products)	21 CFR § 880.6310 (Product Code: OUG)	Specialized medical hardware (such as custom physical protocol-converter boxes, proprietary bedside hardware dongles, or dedicated medical data routers) that does not include off-the-shelf general-purpose IT hardware	Class I (510(k)-exempt) medical device; subject to FDA enforcement discretion (FDA does not enforce registration, listing, premarket review, QMSR, or UDI compliance) provided it performs only MDDS functions
Active Patient Monitoring Systems (Excluded from MDDS)	e.g., 21 CFR § 870.2300 (Cardiac Monitor) / § 870.1025 (Arrhythmia Detector and Alarm)	Software or hardware intended to detect life-threatening events in real time, generate primary clinical alarms requiring immediate bedside intervention, or control therapy delivery	Regulated Medical Device (Class II or Class III): Requires active FDA premarket clearance/approval (510(k)/PMA), design controls, and full QMSR/UDI compliance

Boundary Analysis: MDDS vs. Mobile Medical Apps vs. General Wellness

When designing multi-function digital health platforms (referred to by the FDA as Multiple Function Device Products under FD&C Act § 520(o)(2)), architects must evaluate each distinct software function against three overlapping FDA guidance documents:

1. Policy for Device Software Functions and Mobile Medical Applications (September 2022)

The FDA regulates software based on its intended use and function, regardless of whether it runs on an inpatient server, a web browser, or a consumer smartphone. The Mobile Medical Applications (MMA) guidance establishes three tiers:

• Tier 1 — Non-Device Software Functions: Medical textbooks/reference apps, patient registration/scheduling/billing software, general-purpose communication tools, electronic health records (FD&C Act § 520(o)(1)(C)), and Non-Device-MDDS (§ 520(o)(1)(D)).
• Tier 2 — Device Software Functions Under FDA Enforcement Discretion: Software that may technically meet the definition of a device under Section 201(h) of the FD&C Act but poses low risk to patients, for which the FDA exercises enforcement discretion. Examples include mobile apps that help patients log and track migraine triggers or asthma inhaler usage, provide Condition-Specific educational coaching, automate simple medical calculations (such as BMI, APGAR, NIH Stroke Scale, or Glasgow Coma Scale), or enable patients to share PROMs with their care team.
• Tier 3 — Regulated Device Software Functions (Mobile Medical Apps / SaMD): Software functions that remain under active FDA regulatory oversight because they: (a) connect to a medical device to control its operation, function, or energy delivery (e.g., an app that adjusts an implantable neurostimulator or insulin pump basal rate); (b) transform the mobile platform into a regulated medical device using built-in or attached sensors (e.g., using the smartphone microphone/accelerometer as an electronic stethoscope or sleep apnea diagnostic monitor, or using the camera to diagnose melanoma); or (c) perform patient-specific analysis of medical device data to generate active diagnostic alarms or specific treatment directives.

2. General Wellness: Policy for Low Risk Devices (September 2019)

Under FD&C Act § 520(o)(1)(B) and the FDA’s General Wellness guidance, a product is exempt from device regulation if it is low risk (not implanted, not invasive, does not involve an intervention or technology such as lasers or radiation that may pose a risk to user safety if uncalibrated, and is not raising novel usability/biocompatibility questions) and falls into one of two intended-use categories:

1. Category 1 (Disease-Agnostic Wellness): Claims relate solely to maintaining or encouraging a general state of health or a healthy activity—such as weight management, physical fitness, relaxation/stress management, mental acuity, self-esteem, sleep management, or sexual function—without any reference to diagnosing or treating a disease or condition.
2. Category 2 (Chronic Disease Risk Reduction / Living Well Claims): Claims sustain or offer general improvement to functions associated with a general state of health while referencing a specific chronic disease (such as Type 2 diabetes, hypertension, cardiovascular disease, or anxiety) only where it is well understood and accepted in peer-reviewed scientific literature that healthy lifestyle choices (diet, exercise, sleep, weight control) reduce the risk or impact of that chronic condition.

UDI and Labeling Requirements for Regulated Software as a Medical Device (SaMD)

When a software product crosses out of Non-Device-MDDS, General Wellness, or Enforcement Discretion and becomes a regulated medical device (SaMD), it must comply with the FDA’s Unique Device Identification (UDI) System Final Rule (21 CFR Part 801, Subpart B and 21 CFR Part 830), alongside FDA Computer Software Assurance (CSA) and IEC 62304 lifecycle validation. Under 21 CFR § 801.50, special UDI labeling rules apply to stand-alone medical device software:

• Electronic Distribution Only (Cloud / App Store Download): Stand-alone software that is not distributed in packaged physical form (e.g., no CD-ROM, USB drive, or physical box) is exempt from the requirement to bear an Automatic Identification and Data Capture (AIDC) barcode. Instead, it must provide its UDI (both the fixed Device Identifier [DI] and variable Production Identifier [PI] version string) through an easily readable plain-text statement displayed either (1) whenever the software is started (splash screen) or (2) through a menu command (such as an “About” or “Regulatory Information” screen).
• Packaged Physical Media Distribution: If stand-alone software is also distributed on physical media, the physical package label must bear the full UDI in both easily readable plain-text and machine-readable AIDC (barcode/DataMatrix) formats, in addition to the in-app plain-text screen display.
• When a New UDI-DI Is Required vs. UDI-PI Update: Under 21 CFR § 830.50, major software architecture revisions, changes to clinical algorithms that alter diagnostic performance/safety, operating system platform changes, or new medical claims require assigning a new Device Identifier (UDI-DI) in the FDA Global Unique Device Identification Database (GUDID), whereas minor bug fixes, usability patches, and security updates that do not affect safety or effectiveness are tracked via the version number in the Production Identifier (UDI-PI).

Frequently Asked Questions

What is a Medical Device Data System (MDDS) and when is it exempt from FDA device regulation?

A Medical Device Data System (MDDS) is a hardware or software product intended solely to transfer, store, convert formats (according to preset specifications), or display medical device data without controlling or altering the functions or parameters of any connected medical device and without performing active patient monitoring. Under Section 3060 of the 21st Century Cures Act (FD&C Act § 520(o)(1)(D)), software-only MDDS functions (“Non-Device-MDDS”) are statutorily excluded from the definition of a medical device, while specialized hardware MDDS (“Device-MDDS” under 21 CFR § 880.6310) remain Class I 510(k)-exempt devices under FDA enforcement discretion.

How does the FDA Policy for Device Software Functions and Mobile Medical Applications classify enforcement discretion?

In its September 2022 guidance, Policy for Device Software Functions and Mobile Medical Applications, the FDA divides mobile and clinical software into three regulatory tiers: (1) software functions that are NOT medical devices under FD&C Act § 520(o); (2) software functions that may meet the statutory definition of a device under § 201(h) but pose low risk and are subject to FDA enforcement discretion (meaning FDA does not enforce registration, 510(k), QMSR, or UDI requirements); and (3) regulated Device Software Functions / Mobile Medical Apps that perform active diagnosis, treatment, or physiological device control and require active FDA oversight.

Where is the boundary between a low-risk General Wellness product and a regulated mobile medical app?

Under the FDA’s General Wellness: Policy for Low Risk Devices guidance, a product qualifies as a low-risk General Wellness product outside active FDA regulation if it is non-invasive, poses no safety risk to users, and has either (a) an intended use that relates to maintaining or encouraging a general state of health or healthy activity without any reference to a specific disease or condition, or (b) an intended use that promotes a healthy lifestyle to help reduce the risk of, or help live well with, certain chronic diseases where the role of healthy lifestyle choices is well-understood in peer-reviewed literature.