Update on FDA Regulation of Medical Seth A. Mailhot, Partner Lead, FDA Regulatory Practice Overview

. Applying the Definition of a Device to Software . FDA Policy on Health IT . Mobile Medical Applications Definition of a “Device”

. Sec. 201(h) defines a device as an instrument, apparatus, implement, machine, contrivance, . . . or other similar or related article, including any component, part, or accessory, which is intended: . for use in the diagnosis of disease or other conditions, . in the cure, mitigation, treatment, or prevention of disease, . to affect the structure or function of the body Software That is Not a Medical Device

. Electronic “copies” of medical textbooks, teaching aids or reference materials . Software solely used to log, record, track, evaluate, or make decisions or suggestions related to developing or maintaining general health and wellness Software That is Not a Medical Device (cont.)

. Software that only automates general office operations with functionalities that include billing, inventory, appointments, or transactions . Software that performs the functionality of an electronic health record system or personal health record system, including providing patients a means to access their health records Software That is Not a Medical Device (cont.)

. Software solely used to provide clinicians with training or reinforce training previously received . Software that serves as a generic aid to assist users, but is not commercially marketed for a specific medical indication, such as serving as a magnifying glass, recording audio, note-taking, and replaying audio with amplification Exceptions to Non Device Software Categories

. Software allowing the user to input patient-specific information along with reference material to automatically diagnose a disease or condition is a device . Generic aids promoted for medical applications are devices: . Software that controls a light emitting diode (LED) on a mobile platform is a general aid if the manufacturer intends the system to illuminate objects generally (without a specific device intended use), but… . If the LED-controlling software is promoted by the manufacturer through marketing and distribution for use as a light source to examine patients (such as an ophthalmoscope), then the software would meet the definition of a device Changes from FDASIA Health IT Report

. Joint report issued in April 2014 by FDA, FCC and Office of the National Coordinator for Health Information Technology (ONC) . Groups Health IT functionality into 3 broad categories: 1. administrative health IT functionality, 2. health health IT functionality, and 3. medical device health IT functionality. . Recommends a limited, narrowly-tailored approach that primarily relies on ONC-coordinated activities and private sector capabilities, without the need for any new or additional areas of FDA oversight Health IT Functionality

. Administrative functionality: . admissions, billing and claims processing, practice and inventory management, scheduling, general purpose communications, analysis of historical claims data to predict future utilization or cost-effectiveness, determination of health benefit eligibility, population health management, reporting of communicable diseases to public health agencies and reporting on quality measures . Health management functionality: . health information and data exchange, data capture and encounter documentation, electronic access to clinical results, some clinical decision support, medication management, electronic communication and coordination, provider order entry, knowledge management, and patient identification and matching Policies Announced in Health IT Report

. FDA will focus its oversight on medical device health IT functionality (ex., computer aided detection software and remote display or notification of real- alarms from bedside monitors) . If a product with health management health IT functionality meets the statutory definition of a medical device, FDA does not intend to focus its oversight on the product Implications of FDA Regulation

. Registration and listing (including user fee) . Premarket submission (unless exempt) . Design controls (21 C.F.R. 820.30) . Other good practice requirements (Quality System Regulation) . Reporting of adverse events (MDRs) . Reporting of recalls (corrections or removals) . Other requirements Design Controls

1.Design and development planning . Plans that describe or reference the design and development activities and define responsibility for implementation 2.Design input . Design requirements of the product that are appropriate and address the intended use of the product, including the needs of the user . Design inputs can also include requirements from specifications 3.Design output . Results of a design effort that are essential for the proper functioning of the device and establish that the design conforms to design input requirements

12 Design Controls (cont.)

4.Design review . Documented, comprehensive, systematic examination of a design to evaluate the adequacy of the design requirements, to evaluate the capability of the design to meet these requirements, and to identify problems 5.Design verification . Confirmation that the design output meets the design input requirements

13 Design Controls (cont.)

6.Design validation . Performed under defined operating conditions on initial production units, lots, or batches, or their equivalents to ensure that devices conform to defined user needs and intended uses and includes testing of production units under actual or simulated use conditions 7.Design transfer . Ensure that the device design is correctly translated into production specifications

.Design history . Contains or references the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the design control requirements 14 Software Verification and Validation

. Software verification provides objective evidence that the design outputs of a particular phase of the life cycle meet all of the specified requirements for that phase . Software testing, . Static and dynamic analyses, . Code and document inspections, walkthroughs, and other techniques . Software validation is confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled . Comprehensive software testing, inspections, analyses, and other verification tasks performed at each stage of the software development life cycle . Testing of device software functionality in a simulated use environment, and . User site testing Software Premarket Submission Requirements Software Premarket Submission Requirements (cont.) Software Premarket Submission Requirements (cont.) Special Software Related Device Categories

. Medical Device Data System (MDDS) . Mobile Medical Apps . Laboratory Information System (LIS) . Picture Archiving and Communications System (PACS) . Remote Patient Monitoring System Medical Device Data System (MDDS)

. MDDS is intended to provide one or more of the following uses, without controlling or altering the functions or parameters of any connected medical devices: . The electronic transfer, storage, conversion or display of medical device data of medical device data; . Class I, 510(k) exempt (21 C.F.R. 880.6310) . Recent FDA draft guidance now exercises enforcement discretion over MDDS software, including software for assessing the risk of cardiovascular diseases or for use in diabetes management [21 C.F.R. 880.9(c)(4) and (5)] MDDS (cont.)

. MDDS may include software, electronic or electrical hardware such as a physical communications medium (including wireless hardware), modems, interfaces, and a communications protocol . MDDS does not include devices intended to be used in connection with active patient monitoring Other Software Devices Covered by MDDS Policy

. Medical Image Storage Devices . Provides electronic storage and retrieval functions for medical images . Examples include devices employing magnetic and optical discs, magnetic tape, and digital memory . Class I, 510(k) exempt (21 C.F.R. 892.2010) . Medical Image Communications Devices . Provides electronic transfer of medical image data between medical devices . May include a physical communications medium, modems, interfaces, and a communications protocol . Class I, 510(k) exempt (21 C.F.R. 892.2020) . MDDS guidance extends enforcement discretion to both Similar Software Devices Not Subject to New Policy

. Laboratory Information System (LIS) . Software that handles in vitro diagnostic data related to patient specimen identification, tests requested, results reported, quality control testing, and other aspects of sample analysis . Class I, 510(k) exempt (21 C.F.R. 862.2100) . Picture Archiving and Communications System (PACS) . Software capable of accepting, transferring, displaying, storing, or digitally processing medical images . Class II (21 C.F.R. 892.2050) . Remote Patient Monitoring System . Software that conditions physiological signals so that they can be transmitted via radiofrequency from one location to another for active patient monitoring . Class II (21 C.F.R. 870.2910) Mobile Medical Application (“App”) . Mobile application is either: . a software application executed on a mobile platform, or . a web-based software application tailored to a mobile platform, but executed on a server . Mobile medical application is a mobile app that: . Meets the definition of “device” in section 201(h), and . Either: . is used as an accessory to a regulated medical device; or . transforms a mobile platform into a regulated medical device . Mobile platform: . Commercial off-the-shelf (COTS) computing platforms, with or without wireless connectivity, that are handheld in nature Mobile Medical App (cont.)

. Mobile medical apps fit into the following categories: . Displaying, storing, analyzing or transmitting patient-specific medical device data (if data is in original format, qualifies as an MDDS)* . Controlling a connected medical device (accessory) . Transforms the mobile platform into a regulated medical device (regulated as the device) . Performs patient-specific analysis and diagnosis, or treatment recommendations (regulated same as non-mobile software ) Enforcement Discretion for Mobile Medical Apps

. FDA will exercise enforcement discretion for mobile apps that are not a “mobile medical app,” despite meeting the definition of a device . FDA will also exercise enforcement discretion for mobile medical apps that: . Help patients self-manage their disease or conditions without providing specific treatment or treatment suggestions . Provide patients with simple tools to organize and track health information . Provide easy access to information related to patients’ health conditions or treatments . Help patients document, show, or communicate potential medical conditions to health care providers . Automate simple tasks for health care providers; or . Enable patients or providers to interact with Personal Health Record (PHR) or Electronic Health Record (EHR) systems Examples of Simple Medical Calculations

. Enforcement discretion applies to “simple medical calculations taught in medical schools and are routinely used in clinical practice” . Examples include medical calculators for: . Body Mass Index (BMI) . Total Body Water / Urea Volume of Distribution . Mean arterial pressure . Glascow Coma Scale score . APGAR score . NIH Stroke Scale . Delivery date estimator Other Mobile Medical Apps Subject to Enforcement Discretion

. Help patients with diagnosed psychiatric conditions maintain their behavioral coping skills by providing behavioral techniques or audio messages . Allow users to inquire about herb and drug interactions . Use patient characteristics to provide screening, counseling and preventive recommendations from established authorities . Track medications and provide user-configured reminders . Allow users to collect blood pressure data and share, track, trend or upload it to a personal or electronic health record QUESTIONS? Seth A. Mailhot 601 Pennsylvania Avenue, N.W. Suite 700 South Washington, D.C. 20004-2601 Phone: (202) 747-9566 Cell: (617) 842-0484 Fax: (202) 347-1819 [email protected]

Seth Mailhot is a partner and lead of the FDA Admissions Regulatory Practice Group in Michael Best & . District of Columbia Friedrich’s Washington D.C. office. His 14 years . Massachusetts working in the U.S. Food and Drug Administration (FDA) has provided him a unique . U.S. Patent and Trademark Office perspective when counseling clients on a broad range of matters involving the FDA. Education . New England School of Law, J.D., Seth’s practice includes representation of the Valedictorian, summa cum laude medical device, pharmaceutical, dietary . University of Massachusetts, B.S., supplement, tobacco and food industries, and Chemical Engineering covers both premarket and post-market issues. His practice is focused on development of premarket submission strategies, and FDA enforcement of good manufacturing practices, both domestically and abroad.

30