2011-3321. Medical Devices; Medical Device Data Systems

AGENCY:

Food and Drug Administration, HHS.

ACTION:

Final rule.

SUMMARY:

The Food and Drug Administration (FDA), on its own initiative, is issuing a final rule to reclassify Medical Device Data Systems (MDDSs) from class III (premarket approval) into class I (general controls). MDDS devices are intended to transfer, store, convert from one format to another according to preset specifications, or display medical device data. MDDSs perform all intended functions without controlling or altering the function or parameters of any connected medical devices. An MDDS is not intended to be used in connection with active patient monitoring. FDA is exempting MDDSs from the premarket notification requirements.

DATES:

This rule is effective April 18, 2011. See section IV of this document for more information.

FOR FURTHER INFORMATION CONTACT:

Anthony D. Watson, Center for Devices and Radiological Health, Food and Drug Administration, 10903 New Hampshire Ave., Bldg. 66, Rm. 2516, Silver Spring, MD 20993-0002, 301-796-6296.

SUPPLEMENTARY INFORMATION:

Table of Contents

I. Background

A. Medical Device Data System

B. Statutory Framework

C. Regulatory History of MDDS

II. Overview of This Rulemaking

III. Comments and Responses

A. Classification and Exemption of MDDS

B. Scope of MDDS Classification

C. Clarification of Terms

D. Analysis of Burdens and Regulatory Requirements

IV. Implementation

V. Environmental Impact

VI. Analysis of Impact

A. Background

B. Comments and Responses

C. Cost of the Final Rule

D. Registration and Listing

E. Current Good Manufacturing Practices (CGMP)/QS Regulation/MDR Compliance

F. Premarket Notification

VII. Federalism

VIII. Paperwork Reduction Act of 1995

I. Background

A. Medical Device Data System

An MDDS is a device that is intended to transfer, store, convert from one format to another according to preset specifications, or display medical device data. An MDDS acts only as the mechanism by which medical device data can be transferred, stored, converted, or displayed. An MDDS does not modify the data or modify the display of the data. An MDDS by itself does not control the functions or parameters of any other medical device. An MDDS can only control its own functionality. This device is not intended to provide or be used in connection with active patient monitoring. Any product that is intended for a use beyond the uses (or functions) identified in this final classification rule is not an MDDS and is not addressed by this rule.

B. Statutory Framework

The Federal Food, Drug, and Cosmetic Act (the FD&C Act) (21 U.S.C. 301 et seq.) establishes a comprehensive system for the regulation of medical devices intended for human use. Section 513 of the FD&C Act (21 U.S.C. 360c) establishes three categories (classes) of devices, depending on the regulatory controls needed to provide reasonable assurance of safety and effectiveness. The three categories of devices are class I (general controls), class II (special controls), and class III (premarket approval). General controls include requirements for registration, listing, adverse event reporting, and good manufacturing practice (quality system requirements) (21 U.S.C. 360c(a)(1)(A)). Special controls are controls that, in addition to general controls, are applicable to a class II device to help provide reasonable assurance of that device's safety and effectiveness (21 U.S.C. 360c(a)(1)(B)).

Devices that were not in commercial distribution prior to May 28, 1976, generally referred to as postamendment devices, are classified automatically by statute into class III, without any FDA rulemaking (21 U.S.C. 360c(f)). Postamendment devices that are automatically classified into class III require premarket approval prior to marketing the device, unless the device is reclassified into class I or II.

Reclassification of postamendment devices into class I or class II is governed by section 513(f)(3) of the FD&C Act, formerly section 513(f)(2) of the FD&C Act. This section provides that FDA may initiate the reclassification of a device classified into class III under section 513(f)(1) of the FD&C Act, or the manufacturer or importer of a device may petition FDA for the issuance of an order classifying the device in class I or class II. To change the classification of the device, it is necessary that the proposed new classification have sufficient regulatory controls to provide reasonable assurance of the safety and effectiveness of the device for its intended use. A medical device reclassified into class I or class II may require the submission of a premarket notification to assure safety and effectiveness, unless the device is exempt.

Premarket notifications are not required for certain class I and class II medical devices. Under section 510(l) of the FD&C Act (21 U.S.C. 360(l)), a class I device is exempt from the premarket notification requirements unless the device is intended for a use which is of substantial importance in preventing impairment of human health or it presents a potential unreasonable risk of illness or injury. FDA refers to these criteria as “reserved criteria.” An exemption permits manufacturers to introduce into commercial distribution generic types of devices without first submitting a premarket notification to FDA.

C. Regulatory History of MDDS

Products that are built with, or consist of, computer and/or software components are subject to regulation as devices if they meet the definition of a device contained in section 201(h) of the FD&C Act (21 U.S.C. 321(h)). In 1989, FDA published a draft guidance document, “FDA Policy for the Regulation of Computer Products,” that explained how FDA planned to determine whether a computer-based product and/or software-based product is a device, and how FDA intended to regulate this device type. The document became known as the “Draft Software Policy.” Since 1989, however, the use of computer products and software products as medical devices has grown exponentially. Consequently, FDA determined that because of the history, complexity, and diversity of computer systems and controlling software, it would be impractical to adopt one “software” or “computer” policy to address all computer and software medical devices. The Draft Software Policy was withdrawn, official notice of which appeared in the Federal Register on January 5, 2005 (70 FR 824 at 890).

An appropriate regulatory approach should depend primarily upon the risk the device poses to the patient should the device (software or hardware) fail to perform in accordance with its specifications. This principle, along with FDA's examination of modern medical device networks and computer infrastructures, informs this reclassification of a category of postamendment computer and software devices that can be regulated under a single classification. This medical device has been named a “Medical Device Data System” or “MDDS.” Because an MDDS does not provide new or unique algorithms or functions, FDA has determined that applying general controls, such as the Quality System regulation (QS regulation or QS requirements) (part 820 (21 CFR part 820)), to the design and development of these devices will provide sufficient regulatory control to mitigate any associated risks. Accordingly, FDA is classifying the MDDS into class I.

II. Overview of This Rulemaking

In the Federal Register of February 8, 2008 (73 FR 7498), FDA issued a proposed rule (the proposed rule) to reclassify, upon its own initiative, MDDSs from class III (subject to premarket approval), to class I (subject to general controls). Further, in accordance with section 510(l) of the FD&C Act, the proposed rule set forth that an MDDS intended for use only by a health care professional and that does not perform irreversible data compression would be exempt from the premarket notification requirements, subject to the limitations on exemption in § 880.9 (21 CFR 880.9). Under the proposed rule, if an MDDS were indicated for use by anyone other than a health care professional, or performed irreversible data compression, a premarket notification would be required.

This regulation classifies as class I MDDS only data systems with specific intended uses and functions. Those device data systems that include any uses beyond, or that are for intended uses different from, those identified for an MDDS will remain class III devices. FDA has determined that MDDSs can be regulated as class I devices because general controls provide a reasonable assurance of safety and effectiveness for this device type. In making this determination, FDA has considered that the risks associated with MDDSs are generally from inadequate software quality and incorrect functioning of the device itself. These failures can lead to inaccurate or incomplete data transfer, storage, conversion according to preset specifications, or display of medical device data, resulting in incorrect treatment or diagnosis of the patient. Based on FDA's knowledge of, and experience with, MDDSs, FDA has determined that general controls will provide a reasonable assurance of safety and effectiveness of MDDSs, such that special controls and premarket approval are not necessary to provide such assurance.

The QS regulation is particularly important in our determination that general controls will provide a reasonable assurance of safety and effectiveness for the device. The QS regulation governs the methods used in, and the facilities and controls used for, the design, manufacture, packaging, labeling, storage, installation, and servicing of devices and is intended to ensure that finished devices will be safe and effective (§ 820.1). Accordingly, as discussed in the proposed rule (73 FR 7498 at 7500 and 7501), the application of the QS regulation significantly reduces the risks of inadequate design and unreliable performance associated with an MDDS.

Specifically, the design control provisions (§ 820.30) that apply to the design of class I devices automated with computer software, especially the risk analysis required under § 820.30(g), will ensure that specified design requirements are met, thereby minimizing the risk of an MDDS inaccurately transferring, storing, converting according to preset specifications, or displaying medical device data.

Based on the preamble to the proposed rule, and the comments received in response to the proposed rule, FDA is now finalizing the reclassification of medical device data systems from class III to class I. This classification will be codified at 21 CFR 880.6310. To meet the definition of an MDDS under § 880.6310, a data system must be intended for the “transfer,” “storage,” “electronic conversion * * * in accordance with a preset specification,” or “electronic display” of medical device data, “without controlling or altering the functions or parameters of any connected devices.” This classification excludes any data systems with intended uses outside the scope of this rule, as further described in section III.B of this document.

FDA made some changes to the rule in response to the comments received. Specifically, FDA has revised the rule as follows:

Paragraph (a)(1) has been modified by moving the reference to “without altering the function or parameters of any connected devices” from paragraphs (a)(1)(i) through (a)(1)(iii) to introductory paragraph (a)(1) of the final rule. Furthermore, a reference to “controlling” was added, and “function” was revised as “functions.” These changes were made to avoid redundancy and to clarify that an MDDS can transfer data that controls a connected medical device not initiated by the MDDS.

Paragraph (a)(1)(i) has been modified to remove the reference to the “exchange” of medical device data by an MDDS. This reference was removed to clarify that the intended use of this medical device type is to act as a communication conduit through which medical device data can be transmitted. The word “exchange” could have implied a more active role in data generation or manipulation than that intended for this device type.

Paragraph (a)(1)(ii) has been modified to remove the reference to “retrieval.” FDA made this change because the role of an MDDS relating to data flow is adequately described by the reference to “transfer” functionality in paragraph (a)(1)(i). The MDDS can act as a communication conduit for sending and receiving medical device data.

Paragraphs (a)(1)(iii) and (a)(1)(iv) were reordered to place the conversion function before the display function. FDA undertook this organizational change to provide clarification of MDDS functionality and because this ordering is more logical and easier to follow. There is no substantive change intended from this reordering.

Paragraphs (a)(1)(ii) and (a)(1)(iii) have been modified to remove the words “from a medical device.” FDA removed these words to clarify that for purposes of the data storage and display functions, the direction the medical device data flows—to or from the MDDS—is not important.

Paragraph (a)(2), which in the proposed rule defined medical device data, has been modified. In response to requests for clarification concerning the acceptable system components of an MDDS, paragraph (a)(2) now provides a list of system components that may be included in an MDDS. FDA has determined that medical device data need not be defined in the rule itself. We are, however, providing clarification here regarding what constitutes medical device data. As stated in this final rule, an MDDS only communicates medical device data. For purposes of this rule, data that is manually entered into a medical device is not considered medical device data. However, if manually entered data is subsequently transmitted from a medical device as electronic data it will be considered medical device data. A device that then transmits that data or is intended to provide one of the other MDDS functions with regard to that data may be an MDDS. In response to requests for clarification, the use of “real time, active, or online patient monitoring” in the proposed rule has been replaced to indicate that an MDDS is not “intended to be used in connection with active patient monitoring.”

Paragraph (b) has been modified to exempt all MDDSs from premarket notification requirements (subject to the limitations on exemption in § 880.9). Based on comments received and a review of data compression features in MDDSs and similar device types, FDA has determined not to require premarket notification for MDDSs that feature irreversible data compression. In addition, the limitation on the scope of the premarket notification exemption to use by health care professionals has also been removed. Based on comments received and information FDA has gathered, FDA does not have reason to believe there is a potential unreasonable risk of illness or injury from an MDDS, even when used by someone other than a health care professional. Therefore, FDA is exempting MDDS devices from the premarket notification procedures in subpart E of part 807 (21 CFR part 807) (510(k) requirements), subject to the limitations in § 880.9.

III. Comments and Responses

The comment period for the MDDS proposed rule began on February 8, 2008, and remained open until May 8, 2008. The Agency received comments from 21 different organizations. Comments were received from device manufacturers and related companies; information technology companies and associations; trade organizations representing device manufacturers and other interested parties; professional associations and organizations representing health care practitioners; and health care and consumer advocacy organizations, including individual physicians and hospital/health care organizations.

In general, all the comments recognized the importance of regulating MDDSs as their own device type. The comments generally fell into the following four main categories: (1) Comments on the classification and exemption of the MDDS; (2) comments seeking additional explanation of the scope of the MDDS classification; (3) comments requesting clarification of terms used in the classification regulation; and (4) comments discussing other issues, such as the analysis of burdens and regulatory requirements.

A. Classification and Exemption of MDDS

(Comment 1) It was suggested that the MDDS should be classified as class II, rather than class I. The comment asserted that because MDDSs must send a signal to the medical device transmitting the data, this can increase the risks of the system. As such, this comment suggested that class II special controls, such as standardized formats and languages, in addition to general controls, were needed. One comment recommended that MDDSs be subject to performance standards related to data formats, interoperability, etc.

(Response) FDA disagrees that devices within the scope of this classification should be class II or that performance standards are required. The general controls, particularly the QS requirements, will provide a reasonable assurance of the safety and effectiveness of this device type. These are devices through which medical device data are passively transferred or communicated. In transferring or communicating the data, an MDDS by itself may not alter or control the functioning of any other medical device. Other devices with which an MDDS operates or to which an MDDS is connected may themselves be class I, II, or III devices, depending on their intended uses, and will need to comply with the controls and safeguards applicable to their classification. These controls will address any risks associated with the device's ability to function with data received from or sent to the MDDS. The information available to the Agency, including the comments provided, does not suggest that general controls are insufficient to provide a reasonable assurance of the safety and effectiveness of this device type or that special controls or performance standards are necessary. Because MDDS systems are so varied and these systems and their communication protocols change frequently, FDA believes that special controls would not be particularly effective. To emphasize the passive transfer or communication function of MDDS, however, the reference to the “exchange” function was removed from the rule. This term could imply that an MDDS may actively affect or manipulate the data of or from other devices. We believe the QS regulation and other general controls will provide a reasonable assurance of safety and effectiveness for this device type. The QS regulation requires that manufacturers ensure that devices perform as intended (through design, development, and other quality systems requirements) (part 820). The other general controls, such as labeling requirements and adverse event reporting, ensure that users have information necessary to use the MDDS, and that any problems that occur are reported to FDA (21 CFR parts 801 and 803).

(Comment 2) Comments were received seeking clarification of the term “health care professional” as used in reference to the premarket notification exemption for certain MDDSs in § 880.6310(b). Specific comments suggested that the term “health care professional” should not be limited to those performing medical treatment, but should also include managers, data entry clerks, and others who perform similar administrative tasks. Other related comments stated that the exemption from premarket notification should be extended to devices intended for all users, not just health care professionals, and to all prescription MDDSs. A few comments asked for clarification of whether use of a device to transmit medical device data from a patient device for physician review would be considered lay or professional use. One comment asked whether a system allowing lay users to view data at home, even when they cannot change the data and are not instructed to take any action, would require premarket notification.

(Response) FDA has reconsidered its position regarding requiring premarket notification for MDDSs when intended for use by someone other than a health care professional. FDA agrees that the exemption from premarket notification should be extended to an MDDS intended for any user, not just health care professionals. Under section 510(l) of the FD&C Act, a class I device may be exempt from the premarket notification requirements unless the device is intended for a use which is of substantial importance in preventing impairment of human health, or it presents a potential unreasonable risk of illness or injury. FDA refers to these criteria as “reserved criteria.” Based on the information received, FDA does not have reason to believe that an MDDS, when intended for use by someone other than a health care professional, would present an unreasonable risk of illness or injury. FDA bases this position on the absence of any reported adverse events or other data in the record to indicate that transferring, storing, converting from one format to another according to preset specifications, or displaying medical device data would pose an unreasonable risk when used by someone other than a health care professional. Therefore, we have determined that lay use of an MDDS, either to transmit data from a patient device or to present data to a patient (e.g., for the patient to view the data from home), would not require premarket notification. However, FDA may decide to change the exempt status of MDDS in the future if, through normal reporting mechanisms or otherwise, FDA determines that the use of these devices by someone other than a health care professional poses an unreasonable risk of illness or injury. In response to the comments requesting clarification of the term “health care professional,” FDA is not defining this term because the term is no longer used in the regulation.

(Comment 3) Comments raised the question whether certain devices, such as glucose monitors, would be impacted by the exemption limitation under § 880.9(a), (b), and (c)(5).

(Response) This rule in not intended to change the regulation of glucose monitors, which would not be classified as MDDSs.

B. Scope of MDDS Classification

(Comment 4) Several comments asked for clarification on the intended uses of an MDDS. For example, one comment stated that the rule appeared to indicate there were two device types that fit under the MDDS classification: (1) Those that pass medical data from a source(s) to a destination(s); and (2) clinical user-focused devices that archive and/or display medical device data. Several comments recommended that particular devices, such as automatic backup systems, systems to automate workflow or provide workflow decision support, billing/claims systems, and systems that provide appointment scheduling, should be excluded from MDDS classification. One comment suggested that software functionality such as automating decision support protocols and guidelines, where the manufacturer provides the mechanism but the health care professional enters the detailed protocol information, should be excluded from MDDS classification. A few comments requested clarification with respect to “competent human intervention” from the 1989 Draft Software Policy in determining whether a device is an MDDS.

(Response) In response to these requests for clarification of the intended uses and functionality of an MDDS, FDA has revised the rule. Specifically, FDA has clarified that MDDSs are data systems that transfer, store, convert according to preset specifications, or display medical device data without controlling or altering the function or parameters of any connected medical device—that is, any other device with which the MDDS shares data or from which the MDDS receives data. A system that performs any other function or any additional function is not an MDDS. An MDDS acts only as the mechanism through which medical device data can be transferred, stored, converted, or displayed. An MDDS does not modify, interpret, or add value to the data or the display of the data. An MDDS does not add to or modify the intended uses or clinical functions that are already contained within the medical devices that provide data to (or receive data through) the MDDS. An MDDS by itself does not control the functioning of any other medical device. An example would be in the case of software that would alter the parameters on an infusion pump. The MDDS could pass that control signal to the infusion pump, but the MDDS could not initiate that signal. An MDDS can, however, control its own functionality. It can generate signals to establish and implement communication of medical device data. For example, if a system stores data and contains diagnostic functionality that allows it to perform clinical assessments or clinical monitoring, such as alarm functionality based on preset clinical parameters, that system is not an MDDS. At the same time, a device or system that does not transfer, store, convert, or display medical device data is also not an MDDS. Although we cannot determine, in the abstract, whether a particular workflow or billing system would be an MDDS, systems that do not receive or transmit data from a medical device (i.e., medical device data) would not meet the MDDS definition.

The 1989 Draft Software Policy was withdrawn as indicated in the Federal Register of January 5, 2005 (70 FR 824 at 890). This final MDDS rule should be used for determining whether a device is an MDDS.

(Comment 5) Comments were received requesting clarification of the types of medical device data that can be transmitted via an MDDS. Specifically, one comment suggested that the type of medical device data transmitted via an MDDS be limited to the transmission of medical device data away from a medical device, so as to emphasize the Agency's position that the “report-writing functions of a computer system,” or manual entry of data, would not be considered an MDDS. Several comments suggested that an MDDS was only the device data system that interfaces directly with the device that generated the medical device data, whereas systems which receive the information subsequently would not be an MDDS. One comment suggested that software modules that retrieve, transmit, store, display, transfer, or exchange static representations of medical device data from an MDDS or other medical device are not medical devices.

(Response) FDA agrees that the term “medical device data” could be clarified with regard to the intended functionality of an MDDS. FDA considers medical device data to be any electronic data that is available directly from a medical device or that was obtained originally from a medical device. As FDA explained in the proposed rule, “It is FDA's long-standing practice to not regulate those manual office functions that are simply automated for the ease of the user (e.g., office automation) and that do not include MDDS as described previously. For example, the report-writing functions of a computer system that allow for the manual (typewriter like) input of data by practitioners would not be considered as an MDDS, because these systems are not directly connected to a medical device” (73 FR 7498 to 7500). FDA agrees that any data manually entered into a medical device and not then electronically transmitted is not to be considered medical device data for purposes of this rule; MDDSs are not intended to capture report-writing functions of a computer system. If data that has been manually entered into a medical device is subsequently transmitted from the medical device as electronic data, however, this data will be considered medical device data. Medical device data can be communicated from any connected device, regardless of whether it is received directly from the originating medical device. For example, transmission of “static representations” of medical device data would not preclude a system (or device in that system) from being an MDDS. Accordingly, FDA has removed the words “from a medical device” from the proposed paragraph (a)(1) and has removed the language of proposed paragraph (a)(2) defining medical device data. This standard is not needed in the rule itself, and is being clarified in the preamble instead.

(Comment 6) One commenter asked FDA to clarify that an MDDS can exchange data between medical devices.

(Response) An MDDS is intended to be a communication conduit for medical device data. An MDDS does not create or generate any of its own data, including signals, to be sent to a medical device, other than data relating to the MDDS's own functioning (i.e., self-diagnosis or reports of malfunctioning). But, an MDDS may be used to transmit medical device data that originates from a source that is external to the MDDS either to, or away from, another medical device. To emphasize this intended function of an MDDS, the term “exchange,” in proposed § 880.6310(a)(1)(i) has been removed from the final rule. As stated in the final rule, an MDDS may transmit data between devices so long as it does not control or alter the functions or parameters of those devices.

(Comment 7) Several comments inquired whether Computerized Provider Order Entry (CPOE) systems and electronic prescribing systems would be regulated under the MDDS rule. Several comments also asked whether electronic health record products would be regulated under the MDDS rule. One comment suggested that electronic medical record products used in the perioperative environment should be regulated as class II.

(Response) This rule is limited in scope to devices meeting the definition of an MDDS. It does not address, or consider, other device functionality or an intended use that is outside this definition. For instance, as noted in the proposed rule, “[t]his * * * regulation does not address software that allows a doctor to enter or store a patient's health history in a computer file” (73 FR 7498 at 7500). Moreover, as previously stated, manually entered data is not medical device data unless it is subsequently transmitted electronically. Thus, although we recognize that certain functions of an MDDS might be present in an electronic health record product, we expect electronic health record software generally falls outside the MDDS classification. Moreover, a device or system such as a CPOE system that, for instance, can order tests, medications, or procedures, would not meet the MDDS definition because its intended uses fall outside that definition's scope.

(Comment 8) Many comments asked whether systems already regulated under other specific device type regulations would fall under the MDDS regulation. Specifically, the comments inquired whether certain devices, such as a laboratory information system (LIS) classified as a calculator/data device processing module for clinical use under § 862.2100 (21 CFR 862.2100), or a picture archiving and communications system (PACS) classified under § 892.2050 (21 CFR 892.2050), would fall within the scope of the MDDS regulation.

(Response) FDA intends for the MDDS definition to be broad, to capture systems that feature the functions identified in this rule but that do not fall under another device type regulation. Numerous device classifications exist for products that perform data and information transfer, storage, display, conversion, and/or similar management functions. The MDDS classification only applies to devices that meet the MDDS definition and do not have additional functions that are outside the scope of an MDDS and that fall within an existing classification. An LIS and a PACS (§§ 862.2100 and 892.2050, respectively) are two device classifications that encompass functionality similar to an MDDS, but they have other specific intended uses or features that are outside the scope of the MDDS rule. A PACS may have similar functionality as an MDDS, but a PACS may perform digital processing, unlike an MDDS. Moreover, a PACS deals only with medical images, while an MDDS may deal with images and other medical data. A LIS, classified under the calculator/data processing module for clinical use regulation, may store clinical data; but a LIS is also able to process data, unlike an MDDS. Another device that is potentially similar to an MDDS is a medical image management system (MIMS), classified under the medical image communications device regulation (21 CFR 892.2020). But a MIMS transfers medical images, unlike an MDDS.

If a device meets the definition of a LIS or PACS or other already classified device, the device is within that device type and is regulated accordingly, even if one or more of its intended uses might overlap with the MDDS classification. FDA is not aware of any currently marketed PACS, LIS, or MIMS devices that have the intended use of an MDDS and no other intended uses. If a manufacturer believes its PACS, LIS, or MIMS device meets the definition of an MDDS, it should contact FDA.

(Comment 9) One comment requested clarification regarding the reference in the proposed rule to an MDDS not containing any “new or unique” algorithms, and asked whether a combination of existing algorithms or functions would be considered new or unique. Some comments inquired whether APACHE Medical Systems or Apgar scores would be considered a clinical decision support system.

(Response) For the purposes of this rule, any functionality or algorithms supporting intended uses that are not included in this rule's definition of MDDS would be considered “new or unique.” This MDDS rule does not address whether APACHE or Apgar Scoring would be considered clinical decision support systems. FDA expects that systems such as APACHE decision support systems and software-based Apgar scoring systems generally would perform functions that are outside the scope of an MDDS. MDDSs are intended to perform only certain functions: Transferring, storing, converting in accordance with a preset specification, or displaying medical device data. Any functionality such as processing, characterizing, categorizing, or analyzing the data would be outside the scope of an MDDS. Furthermore, systems that perform any clinical or medical diagnostic function are not considered MDDSs.

(Comment 10) Other comments raised questions regarding whether a database that flags certain data or prioritizes data, or a system that creates data plots or graphs, would be considered an MDDS. Another comment suggested that systems that trend raw data over time could still be an MDDS. One comment asked whether a system that emails a physician when medical data fits pathologic patterns or a system that presents medical data with analytic pattern fit statistics can be an MDDS.

(Response) An MDDS has intended uses that are limited to transmitting, storing, converting according to a preset specification, and displaying data. FDA considers flagging (via email or otherwise), analyzing, prioritizing, plotting, or graphing data to be additional uses that add value or knowledge to the existing data and thereby exceed the limited functionality of an MDDS. An MDDS with a display function is intended only to display data in the same form in which the data was received from a connected medical device. Use of an MDDS for conversion is limited to translation, so that data can be viewed or transmitted in the same form that it was received by the MDDS. An MDDS can convert data into different languages, so that devices or equipment from different vendors can share information. An MDDS cannot, however, interpret the data or change the form in which the data was received by the MDDS. For example, an MDDS could convert data to or from the HL7 format, so that data provided from a connected medical device in spreadsheet form could be displayed in spreadsheet form by the MDDS or another connected device. But numerical data from a medical device connected to an MDDS could not be displayed graphically by the MDDS, nor could the MDDS display graphic data in spreadsheet form or otherwise in a different graphic form.

(Comment 11) FDA received comments inquiring as to the scope of the phrase, “without altering the function or parameters of any connected devices,” in proposed § 880.6310(a). Commenters also asked whether a system that sends data to an infusion pump to control the flow rate, updates clock time on a connected device, sends software updates to, or updates database information embedded in, a connected device would be considered an MDDS.

(Response) As previously described, the language that is the subject of these comments has been slightly modified in the final rule, primarily by adding reference to not “controlling” such functions or parameters and moving this language up to the beginning of paragraph (a). A system that initiates the data or generates the control signal to an infusion pump to control the flow rate would not be an MDDS because, as the revised final rule indicates, generation of data is not an intended use for an MDDS and an MDDS performs its intended uses without “controlling or altering the functions or parameters of any connected devices.” FDA considers a device to control or alter a connected device if, among other things, it generates a signal or other data that controls or alters the functioning of the connected device. Therefore, an MDDS could transfer a signal or other data from an initiating device to the infusion pump in the situation described in the comment. As the final rule states, an MDDS by itself cannot control or alter the parameters or functions of a connected medical device. Rather, the MDDS can be used to transfer data from a non-MDDS initiating device, which when received, will alter the parameters of a connected device. The product that initiates the alteration of the device function would be a medical device that is classified separately from the MDDS. Similarly, any software, or corresponding information technology (IT) system, that issues or creates data or system changes, including the clock time, or modifies any control parameters of any connected device, such as software updates or database information, is not an MDDS.

(Comment 12) Some comments asked whether generation of an email message, or conversion to Hypertext Markup Language (HTML), Portable Document Format (PDF), Health Level 7 (HL7), or similar format, would be considered equivalent to generating a printable format. As described in the proposed rule, “A medical device data system (MDDS) is a device intended to provide one or more of the following uses: * * * [t]he electronic conversion of medical device data from one format to another format in accordance with a preset specification. For example, this would include software that converts digital data generated by a pulse oximeter into a digital format that can be printed.” (73 FR 7498 at 7499 and 7500).

(Response) FDA agrees that an MDDS may convert medical data “from one format to another format in accordance with a preset specification” (§ 880.6310(a)(1)(iii)). A preset specification is a standardized translation of data from the format in which it was received from a medical device to another format in which the data are stored, displayed, or transferred by the MDDS. For example, this may include conversion of data to HTML, PDF, HL7, or similar format. An MDDS may not otherwise convert, alter, modify, or interpret the data that is received from a medical device, and may not change the form in which the data is stored, transferred, or displayed (e.g., from a graph to a spreadsheet).

(Comment 13) FDA received several comments inquiring whether different formats met the definition of “display.” In one comment, FDA was asked to explain whether a “viewer,” which a practitioner can use to review and confirm clinical results for the purpose of patient treatment, would be considered a “display.” Other comments raised the question whether monitors and computer terminals that display medical device data would be considered MDDSs. Still other comments asked FDA to clarify that medical devices with display screens are not MDDSs.

(Response) As stated in this document, systems with display functioning can be considered an MDDS, so long as the device meets the other parts of the MDDS definition; devices would not qualify as an MDDS merely because they have a display screen. As identified in the proposed rule, and discussed elsewhere in this final rule, an MDDS does not include systems that have intended uses for clinical functioning or active patient monitoring. As long as a device with a viewer performs only those functions in the MDDS definition, it would be an MDDS.

(Comment 14) Another comment raised the question whether a device with a data display that overlaid, or superimposed, images would be considered an MDDS.

(Response) FDA cannot determine whether this would be an MDDS without additional information about the device. The device's classification would depend on whether its intended uses were limited to those of an MDDS, including the display of medical device data and converting medical device data according to preset specifications. FDA would also need to determine whether the display functionality provides an additional layer of diagnostic support to the health care professional, such as active patient monitoring, which is not an intended use for an MDDS.

(Comment 15) Many comments asked whether various system constructions and components, in general, would be regulated as MDDSs under § 880.6310. Several comments asked whether “off-the-shelf” software, wireless systems, backup systems, third party equipment, or interfaces would be considered MDDSs.

(Response) FDA has defined an MDDS as a system that transfers, stores, converts according to preset specifications, or displays medical device data. By themselves, any system, or component of a system, that is solely intended for use as general IT equipment (and that is not intended for a device use under section 201(h) of the FD&C Act), would not be considered a medical device.

FDA recognizes that an MDDS, as a system, can consist solely of software, or can feature additional components constructed in many different ways. Such a system can include software, hardware, and the intended architecture, as well as any interfaces and functions of connected devices. Due to the wide variations among these systems, FDA cannot ascertain based on the comments whether specific system constructions or components would meet the definition of an MDDS. To better convey the scope of what FDA considers an MDDS, however, FDA has clarified the rule to indicate that “[a] medical device data system (MDDS) may include * * * a physical communications medium (including wireless hardware), modems, interfaces, and a communications protocol” (§ 880.6310(a)(2)). When the system is validated under the QS regulation (§ 820.30(g)) and in assessing the safety and effectiveness of the device, the entire system, including all components, is considered.^[1]

(Comment 16) Many comments requested clarification on whether a product used with medical devices, such as a glucose meter, blood pressure cuff, or spirometer, is an accessory to a previously classified device, an accessory to an MDDS, or a component of an MDDS. A few comments requested clarification on when software developed to operate with a specific device becomes an accessory to that device, regulated under the principal device's classification, and when it remains an MDDS subject to the MDDS rule. One comment noted that FDA has cleared medical device data software for devices such as glucose meters, blood pressure cuffs, and spirometers as accessories to those devices. One comment suggested that software developed to interface only with a particular device be regulated as an accessory to that particular device type, whereas a product intended to be used with generic/multiple types of devices be regulated as an MDDS. The comment further suggested that labeling for MDDS devices that support generic/multiple device types not be prohibited from specifying particular medical devices with which MDDS software is compatible.

(Response) As indicated in the classification regulation, an MDDS has limited intended uses. In general, these intended uses include the passive transfer or communication of medical device data without controlling or altering the functions or parameters of any connected medical devices. As such, any product that is a medical device, and that supports a function outside the scope of an MDDS intended use, would not be considered an MDDS. If the product meets the definition of an MDDS because it is limited to the intended uses of an MDDS, FDA will regulate such a product as an MDDS, not as an accessory to or component of another device, regardless of how many particular devices or device types the product supports. FDA recognizes that some devices that meet the definition of an MDDS may have been previously cleared as accessories to other device types. Through enactment of this regulation, devices that are considered MDDSs will now be classified as class I, Exempt, whether they are existing devices or new/modified devices that are now defined as MDDS. If some of the intended uses of a device fall outside the scope of the MDDS regulation, then the device would not meet the definition of or be regulated as an MDDS. Finally, the specific content of MDDS product labeling is outside the scope of this rule, and is governed by part 801.

C. Clarification of Terms

(Comment 17) Several comments requested clarification of the term “irreversible data compression.” A few comments requested clarification on whether rounding errors, type conversions, or a loss of fidelity less than the margin of error in the data represented irreversible data compression. Another comment regarding exemption from premarket notification stated that FDA should require premarket notifications for MDDSs that perform “irreversible data compression” only when the MDDS performs irreversible data compressions that can lead to a patient safety risk.

(Response) After reviewing the comments and reviewing device classifications that are potentially similar to the MDDS, FDA has removed the distinction regarding irreversible data compression from the final rule. The safety and effectiveness concern with regard to irreversible data compression is that compressed output data is not an exact replica of the input data. Based on comments received and a review of data compression features in MDDSs and similar device types, FDA has determined not to require premarket notification on the basis of irreversible data compression. FDA has concluded that general controls are sufficient to ensure that any data compression features will not undermine the safety and effectiveness of the device in these circumstances.

(Comment 18) Some comments asked FDA to better define the term “sound an alarm” as used in the proposed rule to characterize a function that an MDDS cannot perform. Other related comments asked about the permissible scope of alarm capabilities of an MDDS. For example, it was suggested that the prohibited alarms be defined as alarms that require positive acknowledgement, cancellation, or clinical impact. Several comments suggested that the definition of an alarm in the MDDS regulations should be consistent with the International Electrotechnical Commission definition (IEC 60601-1-8). Other comments suggested that an MDDS should be permitted to create and detect alarms for low priority physiological conditions. Many comments also noted that if MDDSs could not include an alarm, that would mean an MDDS could not include a signal that the MDDS was malfunctioning. Several comments requested clarification on whether transmitting alarm conditions, including high-priority, real-time alarms, without providing any notification to the user, was acceptable for an MDDS. One comment asked whether displaying the content and timing of an alarm as part of a historical record would exclude a device from the MDDS classification.

(Response) After considering the comments, FDA has removed the term “sound an alarm” from the final regulation. FDA agrees with the comments that an MDDS should be able to include alarms related to its own operational status, such as an alarm announcing a malfunction. FDA recognizes that functions that allow an MDDS to monitor its own operational status are critical to mitigating the risks associated with this device type. Accordingly, FDA considers alarms that monitor the operational status of an MDDS to be an acceptable function within the definition of MDDS.

FDA has further clarified in the final rule that an MDDS excludes any system that does more than transfer, store, convert according to preset specifications, or display medical device data without controlling or altering the functions or parameters of a connected medical device. A device data system that facilitates clinical assessments or monitoring, such as alarm or alert functionality based on preset clinical parameters (including low priority physiological conditions) is not an MDDS. It is permissible for an MDDS to transfer any type of data, including alarms, without analysis or specific recognition of the intent or significance of that data. An MDDS may therefore display or store the content and timing of an alarm generated by a connected device, in the same format as the data was received from the originating device, as part of a historical record.

(Comment 19) Several comments asked FDA to define “real time, active, or online,” and recommended that the MDDS classification should exclude monitoring of data critical to the timely care of the patient, without regard to the time required to process data. Other comments suggested that “real time, active, or online patient monitoring” was confusing and would exclude from the MDDS classification devices intended to transmit medical device data to a physician for the purpose of performing remote patient examinations.

(Response) FDA agrees with the recommendation in the comments with reference to “real time, active, or online patient monitoring”. We have modified the rule to include the word “active” to represent any device that is intended to be relied upon in deciding to take immediate clinical action. A device intended to be used for active patient monitoring (or decision support) is not an MDDS. There are existing classifications for patient monitoring devices.^[2] The detection, measurement, or recording of patient data and other functions of a patient monitoring device are outside the scope of an MDDS. Moreover, as a class I device, an MDDS is not intended to be used in connection with active monitoring that depends on the timeliness of the data transmission, because an MDDS is not subject to controls relating to the speed of transmission and conversion. Any device that 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 is not an MDDS. Such devices are generally accessories to other devices. FDA has changed the final regulation to state that an MDDS “does not include devices intended to be used in connection with active patient monitoring.”

D. Analysis of Burdens and Regulatory Requirements

(Comment 20) Comments inquired how FDA would implement this regulation. These comments inquired as to the deadline for submitting premarket notifications and complying with registration and listing requirements. Several commenters requested an extension of 18 to 24 months for manufacturers to comply with the QS regulations and other controls, because many of the affected entities, such as hospitals acting as MDDS manufacturers, will be creating compliant processes and systems from scratch. Additional related questions pertained to the enforcement of the regulation. Specifically, comments expressed concern with how health care facilities would be regulated, and suggested that a longer period of time be permitted for these facilities to register and list the device, as well as to comply with the QS regulations. One comment requested clarification on how the term “legally marketed” would be interpreted by FDA in determining whether retrospective design controls would be required, given that no MDDS devices have received premarket approval (PMA), as would be required prior to issuance of this final rule in order to have been legally marketed. The comment further suggested that the limitations on 510(k) exemptions under § 880.9 are not applicable provided that the results from the connected device are not displayed to the user.

(Response) FDA recognizes that some MDDSs already on the market are not currently manufactured in accordance with QS and Medical Device Reporting (MDR) requirements. As further discussed in section IV of this document, all manufacturers of MDDSs, including any health care facilities acting as manufacturers, will be required to comply with this regulation, which will become effective 60 days after the date of publication in the Federal Register. FDA expects manufacturers of an MDDS to register and list the device by 90 days after the publication date of this final rule in the Federal Register. FDA expects that all MDDS manufacturers will have established a compliant quality system and MDR system for their devices within 12 months after the effective date of the final rule. Particularly, FDA expects all MDDS manufacturers to establish and maintain adequate design controls as part of their quality system. The Office of Compliance will use existing policies and procedures, such as Form FDA 483 “Inspectional Observations,” warning letters, and other established mechanisms in the regulation of MDDS manufacturers. FDA does not intend to enforce design control requirements retroactively to any currently marketed device that would be classified as an MDDS under this rule; however, FDA does intend to enforce design control requirements for design changes to a currently marketed device once there is a design change. See response to Comments 2 and 17 regarding premarket notification requirements. FDA does not agree that because an MDDS device cannot display results to the user it would always be exempt from 510(k) requirements (i.e., would not be subject to the regulatory limitations on exemptions in § 880.9). MDDSs may be subject to premarket clearance requirements if they exceed the limitations on exemptions (§ 880.9).

(Comment 21) Comments were received from hospital systems and other organizations, inquiring whether certain entities would be subject to the MDDS regulation. Specifically, some comments asked FDA to exclude manufacturers from this regulation if they are not in the business of marketing or selling devices, software, or software components. Other comments asked whether a health care facility or other purchaser that modifies MDDS software or hardware purchased from a vendor would be considered a manufacturer. A few comments noted that it is the customer, and not the manufacturer, who often decides whether MDDSs are connected to other MDDSs or other medical devices, and how these systems interact.

(Response) This final rule establishes the classification and regulatory controls applicable to an MDDS. Manufacturers of MDDSs must comply with these regulatory controls. Manufacturers of software systems or other products that do not have intended uses covered by the MDDS classification would not be subject to this rule. 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. If, however, a user makes any modifications to the MDDS that are outside the parameters of the original manufacturer's specifications for the device, for purposes of the user's clinical practice or otherwise for commercial distribution, that user becomes a manufacturer under the MDDS rule, and as a result is subject to applicable device regulations, including registration and listing and the QS regulation. Likewise, if a user reconfigures any other product into an MDDS for such purposes, that user would also be a device manufacturer subject to applicable regulations. This is consistent with FDA's current definition of a “manufacturer” for purposes of the MDR system, establishment registration and device listing, reports of corrections and removals, and QS regulations (parts 803, 807, 820, and 21 CFR part 806).

(Comment 22) Some comments asked whether a health care facility or other purchaser that buys software or hardware that has not been labeled or otherwise denoted as an MDDS, and that then subsequently utilizes the software or hardware for functionalities within the scope of this MDDS regulation, will be considered a manufacturer. A few comments asked whether device communication protocols incorporated by third-party companies or custom interfaces developed by hospitals would fall within the scope of the MDDS classification.

(Response) For clarity, we interpret the comment to presume that the software or hardware is not modified after purchase. A health care facility or other purchaser that buys software or hardware that has not been labeled or otherwise denoted as an MDDS, but is used as an MDDS, is not considered to be a manufacturer. If, however, the purchaser adds to or modifies any hardware or software such that the software is intended to provide the transfer, storage, conversion according to preset specifications, or display of medical device data (or otherwise modifies the product to render it a medical device) and uses it in clinical practice, the purchaser becomes a device manufacturer in accordance with § 807.3(d). If a third-party company or hospital develops its own software protocols or interfaces that have an intended use consistent with an MDDS, or develops, modifies, or creates a system from multiple components of devices and uses it clinically for functions covered by the MDDS classification, then the entity would also be considered a device manufacturer.

(Comment 23) One comment sought clarification of the applicability of the QS regulation, specifically the applicability of design controls, to an MDDS. A few comments noted that upon issuance of the final rule on MDDS, § 820.30(a)(2)(ii) will need to be updated to add MDDSs.

(Response) The MDDS, at its most basic composition, could be software that automates a system. Accordingly, even though many class I devices are exempt from the design control requirement, the MDDS is already subject to design controls under § 820.30(a)(2)(i) because MDDS devices are automated with software. Manufacturers of MDDSs therefore must comply with these design control requirements, as outlined in section IV of this document.

(Comment 24) A few comments inquired as to how to meet the MDR requirements for MDDSs. Specifically, one comment pertained to whether all MDDS problems should be reported, and asked whether a hospital is responsible for MDRs only for MDDS software problems, or also for problems that may be due to hardware on which MDDS software is running. The comment further asked whether MDDS problems related to malware or viruses should be reported. Another comment asked whether hospitals were responsible for reporting MDDS MDR events even when they cannot be sure which specific MDDS created the reportable event. This comment further referred to existing custom hospital software that meets the definition of an MDDS, and asked whether MDRs would be required for these systems and whether problems detected during upgrades to such systems would be reportable. One comment also recommended the development of a health IT complaint reporting system.

(Response) Manufacturers, including hospitals that develop custom systems that meet the definition of an MDDS, must comply with the MDR requirements in part 803. This reporting obligation applies to events in which a medical device has or may have caused or contributed to a death or serious injury, as well as certain device malfunctions. This rule does not affect a manufacturer's obligations under part 803. Additionally, a device user facility, as defined in § 803.3 to include hospitals, is required to report device-related deaths and serious injuries. This reporting should include all available information on the MDR event, including any information about the role that malware or viruses may have played in the event. As discussed previously, purchasers, including hospitals, are subject to MDR requirements applicable to manufacturers concerning an MDDS to which the hospital has added to or modified any hardware or software. The same requirements apply to hospitals that develop their own software protocols or interfaces that have an intended use consistent with an MDDS. Hospitals that use MDDSs without engaging in these manufacturing activities must report in accordance with the requirements for user facilities. FDA does not currently have any plans for specialized reporting systems for MDDSs.

(Comment 25) Several comments requested clarification on how multi-purpose or modular software and devices would be handled with regard to the MDDS rule. For example, one comment recommended that devices with both diagnostic/therapeutic functionality and MDDS functionality could be partitioned such that the MDDS functionality could be modified without having to submit for premarket review. One comment suggested that separable stand-alone software modules capable of independent operation should be regulated individually based on the intended use of that module, whereas modules that are not intended to operate independently, would be regulated based on the intended use of the entire software system. One comment suggested that devices that comprise a virtual system—for example, a blood pressure cuff that can transmit information used with a cell phone that can receive such information—be regulated independently, and that the combination of such devices should not result in a new device.

(Response) The MDDS regulation does not necessarily prevent modular implementation. Because of the various ways in which an MDDS may be configured and integrated with other medical devices and the potential effect of new configurations on functionality and intended use, it is not possible for FDA to make generalized determinations on whether an MDDS or related software module would require premarket review, nor can FDA determine whether the combination of multiple devices would result in a new device requiring premarket review absent further information about the specific devices. The previous responses to comments regarding accessories and components provide guidance on how particular parts of a system would be regulated under the MDDS rule. Manufacturers should contact FDA regarding questions about regulation of specific devices.

(Comment 26) One comment recommended that FDA provide education sessions and written materials on implementing the QS regulation for MDDSs. Another comment suggested revision to the 1989 Draft Software Policy or the development of new guidance specifying products excluded from MDDS classification, and a methodology for clarifying the regulatory status of products that are excluded.

(Response) FDA believes this final rule and preamble provide an adequate description of the MDDS classification, but FDA will consider providing training and other educational outreach to MDDS manufacturers and users. FDA provides numerous resources to entities seeking guidance on compliance with the QS regulation. The FDA Web site provides device advice and training modules specific to the QS regulation. In addition, manufacturers may contact the Division of Small Manufacturers, International and Consumer Assistance for assistance with QS regulation compliance questions. As previously indicated in section I.C of this document, the 1989 Draft Software Policy has been withdrawn.

(Comment 27) A few comments suggested that FDA hold public hearings/workshops on the proposed regulation to provide clarification on the definition of MDDS and what devices are excluded from the classification, as well as a public forum for discussing the benefits and risks of MDDS systems. A few comments suggested that the comment period for the proposed rule should be extended.

(Response) In issuing this regulation, FDA followed the required rulemaking process (§ 10.40 (21 CFR 10.40)). Through this process, we published a notice of the proposed rule and provided a 90-day public comment period, which is longer than the required 60-day timeframe (§ 10.40(b)(2)). In response, we received comments from 21 organizations, and made several changes to the rule, as noted. Having provided sufficient opportunity for public comment and having weighed those comments, FDA finds no basis for delaying implementation of this rule for an additional comment period. Furthermore, FDA has no plans for public hearings or public forums at this time. FDA is finalizing this rule without a public meeting based on the substantial substantive and constructive comments received during the comment period. As a result, we do not believe a public meeting would add any additional constructive input that would merit delaying implementation of the rule.

(Comment 28) One comment suggested that FDA should perform a study to identify those MDDS systems that present the greatest risk in order to more clearly define categories for possible regulation. The comment further suggested that the MDDS regulation should only apply to software that presents patient safety risk as identified by the proposed study. Another comment suggested that FDA determine the potential impact associated with low-risk MDDS systems on patient safety before implementing the regulation.

(Response) FDA believes that all MDDS devices present some patient safety risk. FDA has determined that MDDSs can be regulated as class I devices, however, because general controls, particularly those contained in the QS regulations, provide sufficient regulatory safeguards to provide a reasonable assurance of safety and effectiveness for this device type. FDA did not receive information from the comments or other sources suggesting that there are other categories of MDDS that are high risk and, therefore, FDA does not believe that there is any need to conduct a more elaborate study or categorization of MDDSs for purposes of this regulation.

IV. Implementation

This rule will become effective 60 days after the date of publication of the final rule. All MDDS manufacturers will be expected to register electronically and list under part 807 within 90 days of the publication of this final rule in the Federal Register. FDA expects all manufacturers of MDDSs to develop and implement a compliant quality system and comply with Medical Device Report requirements within 12 months of the effective date of this regulation.

V. Environmental Impact

The Agency has determined under 21 CFR 25.34(b) that this reclassification action is of a type that does not individually or cumulatively have a significant effect on the human environment. Therefore, neither an environmental assessment nor an environmental impact statement is required.

VI. Analysis of Impact

FDA has examined the impacts of the final rule under Executive Order 12866 and the Regulatory Flexibility Act (5 U.S.C. 601-612), and the Unfunded Mandates Reform Act of 1995 (Pub. L. 104-4). Executive Order 12866 directs Agencies to assess all costs and benefits of available regulatory alternatives and, when regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety, and other advantages; distributive impacts; and equity). The Agency believes that this final rule is not a significant regulatory action under the Executive order.

The Regulatory Flexibility Act requires Agencies to analyze regulatory options that would minimize any significant impact of a rule on small entities. As FDA explained in the proposed rule, FDA has been exercising enforcement discretion up to now with respect to class III requirements on MDDSs, but ongoing enforcement discretion may not be a viable long-term regulatory alternative (73 FR 7498 at 7501 and 7502). Because this rule is therefore deregulatory, creates no new burdens in addition to those that exist already under the FD&C Act, and will relieve manufacturers of the cost of complying with existing legal requirements applicable to Class III devices in the future, the Agency certifies that the final rule will not have a significant economic impact on a substantial number of small entities.

Section 202(a) of the Unfunded Mandates Reform Act of 1995 requires that Agencies prepare a written statement, which includes an assessment of anticipated costs and benefits, before proposing “any rule that includes any Federal mandate that may result in the expenditure by State, local, and tribal governments, in the aggregate, or by the private sector, of $100,000,000 or more (adjusted annually for inflation) in any one year.” The current threshold after adjustment for inflation is $135 million, using the most current (2009) Implicit Price Deflator for the Gross Domestic Product. FDA does not expect this final rule to result in any 1-year expenditure that would meet or exceed this amount.

A. Background

An MDDS is a device that electronically transfers, stores, converts according to preset specifications, or displays medical device data. It does not provide any diagnostic or clinical decisionmaking functions. It does not modify data or the display of data. The MDDS device is currently classified into class III, the highest level of regulatory oversight. The MDDS was initially placed in this classification by default.

We published a regulatory impact analysis as part of the proposed rule in the Federal Register of February 8, 2008. In that analysis, we described that in the absence of continuing enforcement discretion, changing the classification for an MDDS from the default class III (premarket approval) to class I (general controls) would be deregulatory. The cost of complying with the requirements for general controls under class I is a small fraction of the cost of complying with the premarket approval requirements under class III. MDDS manufacturers, as makers of class III devices, bear all costs associated with premarket approval, including the cost of submitting the premarket approval application (PMA) and payment of user fees. The costs associated with the submission of the PMA are substantial, potentially reaching $1,000,000.

B. Comments and Responses

In the analysis accompanying the proposed rule, we requested information on the size of the MDDS industry, but received no comments on that issue. FDA did receive seven comments on the regulatory impact analysis.

(Comment 1) There were three comments asserting that the costs of compliance for large health care organizations could be greater than what had been estimated in the proposed rule and would be a burden to some of these organizations. One of these comments stated that if the definition of an MDDS was overly broad, compliance costs could be in excess of $100 million.

(Response) FDA believes the comments misinterpret the definition of an MDDS. The comments reference systems of Electronic Health Records (EHRs) and Personal Health Records (PHRs). 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. This rule only addresses those medical devices that meet the MDDS definition. Moreover, health care organizations purchasing off-the-shelf software and using this software according to the product labeling will not be subject to regulation. In any event, a narrower MDDS definition could render more devices subject to the more burdensome class III requirements.

(Comment 2) There were three comments citing published data to claim costs of compliance could be substantially greater than estimated in the proposed rule and that the burden could be expected to exceed the threshold amount of $135 million.

(Response) FDA believes the cited estimates do not apply to this rulemaking because the source analysis projects burdens associated with EHR, PHR, and radiology information systems (RISs). EHR and PHR systems are not included in this rulemaking, and RIS are already regulated and would not be affected by this final rule. Moreover, the burden of complying with class III requirements is significantly greater.

(Comment 3) A comment asked that FDA include in its Analysis of Impact an estimate of costs associated with developing and implementing the necessary systems to ensure compliance with FDA's MDR requirements, as many MDDS manufacturers are non-traditional medical device manufacturers. The comment noted that IT companies could have products being used in both MDDS and non-MDDS applications.

(Response) In the analysis of impacts in the proposed rule, FDA estimated costs of complying with FDA's QS and MDR regulations. Although specific requirements may initially be unfamiliar to some manufacturers, FDA believes most manufacturers' existing quality systems would need only minimal modification to bring them into compliance, if they are not already. FDA notes that IT companies selling equipment marketed for general IT use and not marketed for MDDS intended uses would not be subject to MDDS regulation, whether or not the product may be used in an MDDS application. FDA reiterates that the cost of complying with QS and MDR regulations is not a burden imposed by this rulemaking. These are burdens that manufacturers already incurred, notwithstanding FDA's exercise of enforcement discretion with regard to manufacturers of MDDS devices.

FDA's initial estimate of a one-time cost to comply with FDA's QS and MDR regulations assumes that manufacturers already have quality practices in place, including complaint-handling systems. FDA is not aware of any MDDS manufacturers lacking good business practices, including quality systems. Nevertheless, FDA cannot be sure of the extent to which all manufacturers have in place quality systems that can be easily modified to meet the requirements of QS and MDR regulations. Costs to a manufacturer would depend on the state of its quality systems, but would likely be less than $20,000 for the manufacturer to bring its quality system into compliance. Total costs could exceed $20,000 if the manufacturer also needed to hire a full time employee to manage the quality system. If a firm does not have any quality system, FDA estimates it would incur a one-time cost of less than $20,000 to establish the appropriate procedures, and would then likely need to hire a full time employee to manage the quality system. Comments to the proposed rule estimated an additional employee with regulatory compliance subject matter expertise to cost $143,000 annually, including salary and benefits. The estimated cost to a firm without a quality system would therefore be an initial amount up to $20,000 to establish the system and then $143,000 annually thereafter. Of course, these would not be burdens associated with this rulemaking; they are existing burdens that a manufacturer already faces notwithstanding FDA's decision to exercise enforcement discretion up to this point.

(Comment 4) A comment claimed that the exclusion of decision support functionality from MDDSs would place a large number of devices into class II, increasing the regulatory cost to industry.

(Response) FDA disagrees with this comment. This final rule will not change the classification of any devices other than MDDSs, and serves only to reduce the statutory and regulatory burdens associated with devices in the MDDS classification.

(Comment 5) A comment asked that FDA conduct an analysis of the impact of the proposed rule on existing MDDS manufacturers, including an assessment of risks and benefits and the costs of compliance.

(Response) This analysis considers the impact of the rule on MDDS manufacturers, and we have considered the comments received on this topic. As previously discussed, this final rule will move MDDS devices from class III to class I, and thus to a less costly set of requirements. As a result, this action is relieving manufacturers of burdens they would otherwise bear.

Through this final rule, FDA will reclassify MDDS devices from the class III default to class I. The application of general controls, including the software design controls in part 820, will be consistent with the principle of applying the least degree of regulatory control necessary to provide reasonable assurance of safety and effectiveness. The application of this lowest level of regulatory oversight will be consistent with the treatment of other devices with similar risk profiles. Software used to store, transmit, and communicate patient medical data, such as LISs and Medical Image Communication Systems, is typically classified into class I.

FDA has already recognized that the class III requirements are not necessary for ensuring the safety and effectiveness of MDDS devices and has been exercising enforcement discretion with MDDS device manufacturers. These firms have not been required to submit PMAs or meet other requirements typically required of manufactures of class III devices. The Agency believes all or nearly all firms in this industry have in place good business practices, including quality systems. If FDA were to discontinue enforcement discretion, most firms would comply with the class I provisions.

C. Cost of the Final Rule

This final rule is deregulatory. Device manufacturers currently subject to class III requirements will be subject to the less burdensome requirements for the makers of class I devices. Of course, changing the device classification may not have any financial impact on the practices of MDDS manufacturers if FDA were to continue its practice of enforcement discretion and to the extent such manufacturers are not already complying with the class III requirements. For the purposes of this analysis, however, we recognize that continued exercise of enforcement discretion will not be permanent. The regulatory alternatives are therefore the class III, class II, or class I controls, enforced by the Agency consistent with the FD&C Act. This final rule will re-classify MDDS devices as class I, which will reduce the applicable regulatory requirements.

Manufacturers of class I devices are required to follow general control requirements, which include: (1) Register and list their MDDS devices with the Agency, (2) conform to applicable medical device current good manufacturing practice requirements (part 820), and (3) comply with MDR requirements (part 803). This final rule exempts MDDS devices from premarket notification unless they exceed the limitations on 510(k) exemptions found in § 880.9.

D. Registration and Listing

The majority of MDDS manufacturers will incur a cost to register and list their devices with the Agency. We estimate this burden to be less than 1 hour per year for manufacturers familiar with this requirement, and up to 2 hours per year for manufacturers not currently producing any FDA-regulated devices (and therefore unfamiliar with the requirement). Manufacturers will also face user fees of $2,179 in fiscal year (FY) 2011 to register and list their devices with the Agency. These fees will rise to $2,364 in 2012. These fees do not represent a cost imposed by this final rule, but a cost that manufacturers may not have yet incurred because of FDA's practice of enforcement discretion with manufacturers of MDDS devices.

E. Current Good Manufacturing Practices (CGMP)/QS Regulation/MDR Compliance

Based on experience with the MDDS and similar devices, FDA believes that most manufacturers of these devices already have quality systems in place as part of good business practices. Good quality systems would include complaint-handling procedures. FDA's QS requirements are flexible and FDA believes that these manufacturers will be able to conform their systems to FDA requirements with little difficulty or cost. Manufacturers are already required to report to FDA whenever they learn that their device may have caused or contributed to a death or serious injury to a patient. The costs of complying with these requirements will be relatively small, but will vary depending on the number and nature of the devices manufactured and the state of the firm's existing quality system. Based on our understanding that the industry generally has in place measures to ensure quality, we believe most firms will be able to adapt their systems to meet FDA's QS and MDR regulations for not more than $20,000. This cost would not be imposed by this final rule; it is an existing burden that manufacturers may not have fully incurred because of FDA's exercise of enforcement discretion with manufacturers of MDDSs.

Because manufacturers have not been required to register and list, we cannot be positive all firms have existing measures to ensure quality, and we cannot rule out the possibility that some manufacturers will face greater costs. If a manufacturer has no quality system in place, we estimate that it would cost less than $20,000 to establish a quality system plus the annual cost of a full-time employee to manage such a system. Comments to the proposed rule estimated the cost of such an employee, including benefits, to be $143,000 per year.

F. Premarket Notification

With the issuance of this final rule and the classification of MDDSs into class I, a manufacturer of an MDDS would not need to comply with the PMA requirement that applies to class III devices or submit a premarket notification. For those MDDSs that exceed the limitations on 510(k) exemptions found in § 880.9, the required premarket notification for an MDDS will be far less complex than submission of a PMA. The cost of preparing and submitting such a notification would be several thousand dollars. The user fees for a premarket notification would be $4,348 for FY 2011, increasing to $4,717 in 2012. In contrast, the cost of submitting a PMA can reach $1,000,000, plus user fees of an additional $236,298 in FY 2011, increasing to $256,384 in FY 2012.

In summary, this device reclassification final rule will substantially reduce an existing legal burden on the manufacturers of MDDSs. The burden of compliance with the general controls provisions applicable to the manufacturers of all class I devices is attributable to statutory requirements that already apply but in the past have not been enforced for MDDSs. Because continued exercise of enforcement discretion may not be a viable long-term regulatory alternative, this final rule reduces the ultimate regulatory burden for manufacturers of MDDSs. Considering the cost of submitting a PMA plus the relevant user fees, the reduction could be $1,000,000 per device.

The Regulatory Flexibility Act requires Agencies to analyze regulatory options that would minimize any significant impact of a rule on small entities. Because reclassification of the affected devices from class III to class I will relieve manufacturers of the cost of complying with the premarket approval requirements of section 515 of the FD&C Act (21 U.S.C. 360e), the Agency certifies that this final rule will not have a significant economic impact on a substantial number of small entities.

VII. Federalism

FDA has analyzed this final rule in accordance with the principles set forth in Executive Order 13132. FDA has determined that the rule does not contain policies that have substantial direct effects on the States, on the relationship between the National Government and the States, or on the distribution of power and responsibilities among the various levels of government. Accordingly, the Agency has concluded that the rule does not contain policies that have federalism implications as defined in the Executive order and, consequently, a federalism summary impact statement is not required.

VIII. Paperwork Reduction Act of 1995

This final rule contains no collections of information. Therefore, clearance by the Office of Management and Budget under the Paperwork Reduction Act of 1995 is not required.

List of Subjects in 21 CFR Part 880

• Medical devices

Therefore, under the Federal Food, Drug, and Cosmetic Act and under authority delegated to the Commissioner of Food and Drugs, 21 CFR part 880 is amended as follows:

PART 880—GENERAL HOSPITAL AND PERSONAL USE DEVICES

1. The authority citation for 21 CFR part 880 continues to read as follows:

Authority: 21 U.S.C. 351, 360, 360c, 360e, 360j, 371.

2. Section 880.6310 is added to subpart G to read as follows:

§ 880.6310

Medical device data system.

(a) Identification. (1) A medical device data system (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:

(i) The electronic transfer of medical device data;

(ii) The electronic storage of medical device data;

(iii) The electronic conversion of medical device data from one format to another format in accordance with a preset specification; or

(iv) The electronic display of medical device data.

(2) 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.

(b) 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.

Dated: February 9, 2011.

Nancy K. Stade,

Deputy Director for Policy, Center for Devices and Radiological Health.

Footnotes

1.  An MDDS manufacturer must comprehensively monitor and address safety and performance concerns of communication methods, including wireless technologies, in the design phase and throughout the product life cycle under the QS regulation (§§ 820.30(g), 820.70, 820.90, and 820.100). Examples of such safety considerations include data corruption or loss of data; timeliness of data delivery; and electromagnetic compatibility.

2.  See, e.g., 21 CFR part 880, subpart C (general hospital and personal use monitoring devices); 21 CFR part 868, subpart C (anesthesiology monitoring devices); 21 CFR part 884, subpart C (obstetrical and gynecological monitoring devices); and 21 CFR part 870, subpart C (cardiovascular monitoring devices).