[Federal Register Volume 76, Number 31 (Tuesday, February 15, 2011)]
[Rules and Regulations]
[Pages 8637-8649]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2011-3321]


=======================================================================
-----------------------------------------------------------------------

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Food and Drug Administration

21 CFR Part 880

[Docket No. FDA-2008-N-0106] (formerly Docket No. 2007N-0484)


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

[[Page 8638]]

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

[[Page 8639]]

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 Sec.  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 (Sec.  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 (Sec.  820.30) that 
apply to the design of class I devices automated with computer 
software, especially the risk analysis required under Sec.  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 Sec.  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 
Sec.  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

[[Page 8640]]

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 Sec.  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 Sec.  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 Sec.  880.9(a), (b), and (c)(5).

[[Page 8641]]

    (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 
Sec.  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

[[Page 8642]]

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 Sec.  
862.2100 (21 CFR 862.2100), or a picture archiving and communications 
system (PACS) classified under Sec.  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 (Sec. Sec.  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 Sec.  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

[[Page 8643]]

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'' (Sec.  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 Sec.  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'' 
(Sec.  880.6310(a)(2)). When the system is validated under the QS 
regulation (Sec.  820.30(g)) and in assessing the safety and 
effectiveness of the device, the entire system, including all 
components, is considered.\1\
---------------------------------------------------------------------------

    \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 (Sec. Sec.  
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.
---------------------------------------------------------------------------

    (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

[[Page 8644]]

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

[[Page 8645]]

``does not include devices intended to be used in connection with 
active patient monitoring.''
---------------------------------------------------------------------------

    \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).
---------------------------------------------------------------------------

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 Sec.  
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 Sec.  880.9). 
MDDSs may be subject to premarket clearance requirements if they exceed 
the limitations on exemptions (Sec.  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 Sec.  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, Sec.  820.30(a)(2)(ii) will need to be updated to 
add MDDSs.
    (Response) The MDDS, at its most basic composition, could be 
software

[[Page 8646]]

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 Sec.  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 Sec.  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 (Sec.  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 
(Sec.  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

[[Page 8647]]

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

[[Page 8648]]

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 Sec.  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

[[Page 8649]]

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 Sec.  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

0
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.


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


Sec.  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 Sec.  880.9.

    Dated: February 9, 2011.
Nancy K. Stade,
Deputy Director for Policy, Center for Devices and Radiological Health.
[FR Doc. 2011-3321 Filed 2-14-11; 8:45 am]
BILLING CODE 4160-01-P