Medical Devices; Medical Device Data Systems, 8637-8649 [2011-3321]

Agencies

• Food and Drug Administration
• DEPARTMENT OF HEALTH AND HUMAN SERVICES

[Federal Register Volume 76, Number 31 (Tuesday, February 15, 2011)]
[Rules and Regulations]
[Pages 8637-8649]
From the Federal Register Online via the Government Printing 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 phon