On February 15, 2011, the Food and Drug Administration (FDA or the Agency) issued a long-awaited final rule reclassifying Medical Device Data Systems (MDDS) as class I, 510(k)-exempt, medical devices. The final rule comes almost three years after the Agency's February 8, 2008, issuance of a proposed rule seeking to classify MDDS as class I, 510(k)-exempt.  

Final rule

The final classification regulation, which modifies 21 C.F.R.

§ 880, reads as follows:

§ 880.6310 Medical device data system.

  1. Identification.
  1. A MDDS is a device that is intended to provide one or more of the following uses, without controlling or altering the functions or parameters of any connected medical devices:
  1. The electronic transfer of medical device data;
  2. The electronic storage of medical device data;
  3. The electronic conversion of medical device data from one format to another format in accordance with a preset specification; or
  4. The electronic display of medical device data.
  1. An MDDS may include software, electronic, or electrical hardware such as a physical communications medium (including wireless hardware), modems, interfaces, and a communications protocol. This identification does not include devices intended to be used in connection with active patient monitoring.
  1. Classification. Class I (general controls). The device is exempt from the premarket notification procedures in subpart E of part 807 of this chapter, subject to the limitations in § 880.9.

Notably, the final rule contains a number of changes compared to the previously proposed rule. Specifically, there were several noteworthy changes in the wording of the final rule compared to the proposed rule:

  • Users - The FDA has removed the requirement that a class I, 510(k)-exempt, MDDS must be for use by a healthcare professional. Previously the Agency raised concerns that products for lay users and other, non-healthcare professionals, might involve additional safety issues. However, the Agency has reconsidered that position and the final rule removes the requirement that the product be for use by a healthcare professional. Thus, any product meeting the definition in the regulation would fall into the class I, 510(k)-exempt, category, even if it were for use by those who are not healthcare providers.
  • Alarms - The FDA eliminated the language of the proposed rule that would have excluded products that sounded an alarm. The FDA clarified that an MDDS may transfer/store/display alarm data as it would any other data, but may not create or interpret that data. The Agency also noted that an MDDS product may need to "sound an alarm" to indicate problems with its own functionality.
  • Active patient monitoring - The language of the final rule was clarified to explicitly exclude use of the product in active patient monitoring. If the system "transmits, stores, converts, or displays medical device data that is intended to be relied upon in deciding to take immediate clinical action or that is to be used for continuous monitoring by a health care professional, user, or the patient" then the system is not an MDDS. The FDA explains that such products are generally accessories to the connected monitoring devices.
  • Definition of Medical Device Data - The originally proposed definition of "medical device data" was removed from the final rule. In the preamble to the final rule the FDA explains that medical device data is "any electronic data that is available directly from a medical device or that was obtained originally from a medical device." Further, the Agency comments that medical device data does not include data manually entered into a medical device unless that "data" is subsequently transmitted electronically. Thus, it isn't regulated data at the point where it is entered into a "medical device," but if the system subsequently sends it elsewhere, it may become regulated data.
  • Irreversible data compression - The proposed rule would have excluded products that performed "irreversible data compression." Under the final rule, such a function would not, in and of itself, put an MDDS into the category of products requiring premarket notification.
  • MDDS role - The FDA made several revisions intended to clarify the role that an MDDS may play. Specifically, the Agency wished to clarify further that an MDDS may not control or alter the parameters or functions of a connected medical device. For example, an MDDS may pass through data that "controls" a connected medical device, but may not itself generate such data. Similarly, the FDA removed the term "exchange" from the definition of an MDDS because it was thought that this term implied too active of a role. The Agency wished to emphasize that the MDDS role is generally fairly passive. For the same reasons, the FDA eliminated the term "retrieval."

Other key observations

In addition to the specific changes to the classification regulation highlighted above, the preamble also contains several important comments and clarifications:

  • The preamble notes that an MDDS may convert data from one form to another (e.g., to or from HL7 format), but goes on to explain that this conversion function is limited to "translation." An MDDS cannot interpret or analyze the data and cannot, for example, convert numerical data to a graphical display.
  • Interestingly, it appears that an MDDS does not necessarily need to connect directly to a medical device. Rather, it is an MDDS if it is transferring, storing, converting, or displaying medical device data, regardless of direct connection to a regulated medical device.
  • Consistent with the changes noted above regarding the sounding of alarms, the FDA explains that an MDDS cannot flag (via email or otherwise), analyze, prioritize, plot, or graph data. The FDA considers these to be functions that "add value or knowledge" to the existing data and, therefore, exceed the functionality of an MDDS.
  • Regarding Electronic Health Records, the FDA notes that "although an EHR or PHR system, or a portion of such a system, may constitute a medical device, these are explicitly excluded from this rulemaking." Similarly, the FDA specifically notes that Computer Physician Order Entry (CPOE) systems would likely fall outside of the limited intended use of an MDDS. In addition, the FDA has clarified that radiology information systems (RIS) are already regulated and would not be effected by this rule.
  • Also of note, if a product is only intended for general IT use and does not otherwise meet the definition of a medical device, then it would not be considered a regulated product under the final rule.

Implementation period

The preamble to the final rule explains that the following timelines will apply with respect to implementation of the final rule:

  • The regulation will become effective 60 days after the date of publication in the Federal Register (April 16, 2011).
  • All MDDS manufacturers must register and list their products with FDA within 90 days after the date of publication in the Federal Register (May 16, 2011).
  • All MDDS manufacturers must establish a compliant quality system and Medical Device Reporting (MDR) system within 12 months of the effective date of the final rule (April 16, 2012).

In particular, with respect to manufacturing and MDR compliance, the preamble to the final rule highlights the design control requirements of the Quality System Regulation (QSR) as being of particular importance for these products. However, the Agency notes that it does not intend to enforce design control requirements retroactively to any currently marketed device. Nonetheless, FDA does intend to enforce design control requirements for future design changes made to currently marketed devices.


While several of the changes to the final classification regulation expand the scope of products that might meet the MDDS definition, such as removal of the requirement that a class I, 510(k)-exempt, MDDS must be for use by a healthcare professional, the final rule remains relatively narrow in scope. The Agency repeatedly notes in the final rule that if a product performs any other or additional functions beyond the functions outlined in the final regulation, then the product does not qualify as an MDDS. Thus, if a product performs all of the functions outlined in the regulation, but also, for example, can be used to order medications, then the product would not be an MDDS. In theory, if the product is not otherwise classified (e.g., as an accessory to another medical device), then it would be considered a class III product. However, the preamble to the final rule suggests that FDA intends to issue additional classification regulations that would potentially cover other software products. Nonetheless, for those products meeting the definition in the regulation and not performing additional functions outside the scope of the rule, the products will be considered class I, 510(k)-exempt, subject to the limitations on premarket notification exemption outlined in the regulation.

Impact on software products currently regulated as accessories to Class II Devices: Interestingly, some products that have historically been regulated as accessories to medical devices and, therefore, classified consistent with the classification of that parent device, will now be considered class I, 510(k)-exempt devices. For example, there are a number of software products designed to be used with handheld glucose meters. These software products have historically been considered class II devices, consistent with the classification of glucose meters. However, under the new regulation, depending on the specific features of the software, these products may now be considered class I, 510(k)-exempt devices.

Impact for hospitals and healthcare systems: Notably, hospitals and healthcare organizations, many of which develop or purchase for use systems that would be considered MDDS, will need to carefully assess the applicability of the MDDS rule, and how actions taken with respect to those data systems might turn them into a "manufacturers" under the regulations. FDA has clarified that a purchaser of an MDDS who has only used, configured, or modified the MDDS in accordance with the original manufacturer's labeling, instructions for use, intended use, original design, and validation would not be considered a manufacturer for purposes of this regulation. As such, compliance with the MDDS regulation would not be required. If, however, a user makes any modifications to the MDDS that are outside the parameters of the original manufacturer's specifications for the device, then that user becomes a manufacturer under the MDDS rule, and as a result, would be subject to applicable device regulations, including registration, listing and the QSR. Similarly, if a user reconfigures any other product into an MDDS for such purposes or creates an entirely new product meeting the MDDS definition, that user would also be a device manufacturer subject to applicable regulations. Accordingly, hospitals and healthcare organizations will need to carefully assess the development, use and reconfiguration of data systems that may be considered MDDS.

Mobile phone applications as MDDS: In light of the removal of the restriction for use by healthcare professionals only, the final rule is applicable to data systems intended for use by non-healthcare, lay users. Conceivably, many types of mobile phone software applications that allow for the transfer, storage, conversion, or display of medical device data may be considered MDDS. Developers of these applications will need to consider the potential applicability of the MDDS classification regulation and the impact of certain features and/or functions on the applicability of this classification. In such cases where these mobile phone software apps meet the definition of an MDDS, developers of these apps will need to comply with the Quality System (QS) and MDR requirements as medical device manufacturers.