[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