Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views TOWARD STIMULATING A BROADER VIEW (not approved, barely proof-read) Draft 07/07/13

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views From the Federal Register “The Food and Drug Administration (FDA), Office of the National Coordinator for Health Information Technology (ONC), and Federal Communication Commission (FCC) seek broad input from stakeholders and experts on the elements we should consider as we develop a report that contains a proposed strategy and recommendations on an appropriate, risk-based regulatory framework for health IT, including mobile medical applications, that promotes innovation, protects patient safety, and avoids regulatory duplication.” Accordingly, the FDASIA Workgroup is charged with providing input on issues relevant to the report FDA, ONC, and FCC will develop, which include: Types of risk that may be posed by health IT that impact patient safety, the likelihood that these risks will be realized, and the impact of these considerations on a risk- based approach; Factors or approaches that could be included in a risk-based regulatory approach for health IT that also promote innovation and protect patient safety; and Approaches to avoid duplicative or overlapping regulatory requirements.

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views From the Federal Register Under III. Topics for Discussion: 1. Taxonomy… 2. Risk and Innovation… 3. Regulation a. Are there current areas of regulatory overlap among FDA, ONC, and/or FCC and if so, what are they? Please be specific if possible. b. If there are areas of regulatory overlap, what, if any, actions should the agencies take to minimize this overlap? How can further duplication be avoided?

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views Process over the last week Discussion of the Regulations Subgroup over the last week: 1. Are the three regulatory systems – ONC, FCC and FDA – deficient in any way with regard to how HIT is regulated? (July 1, except reporting which will be on July 3) 2. Are there ambiguities in the three regulatory systems that need to be clarified so that HIT vendors and others can proceed more easily to innovate? (July 3) 3. Do any of the three regulatory systems duplicate one another, or any other legal, regulatory or industry requirement? (July 3) For Today (July 8) Is there a better way to assure that innovation is permitted to bloom, while safety is assured?

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views FDA issues where attention needed ItemIssue: A or B Description of challenge Wellness/disease borderline A & BFDA needs to explain how to discern disease related claims from wellness, and needs to deregulate low risk disease related claims Accessory issuesA & BFDA needs to explain its position on which basic IT elements are regulated when connected to a medical device, and deregulate or down-regulate those that are low risk CDS softwareAFDA needs to explain which forms of clinical decision support software it regulates Software modularization AFDA needs to specify its rules for deciding the regulatory status of software modules either incorporated into a medical device, or accessed by a medical device A = Ambiguous and B = Broken at the written law level

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views FDA issues where attention needed ItemIssue: A or B Description of challenge Intended use issues AFDA needs to explain how the concept of intended use will be applied to standalone software where the use might evolve over time, perhaps using risk management and post-market surveillance to manage the risks associated with the evolution in the intended use QS application to standalone software AFDA needs to explain how the quality system requirements and facility registration apply to manufacturing of standalone software Premarket requirements for interoperable devices AFDA needs to adopt a paradigm for reviewing software that is intended to be part of a larger, but unspecified Post-market requirements for networks A & BResponsibilities for reporting adverse events and conducting corrective actions can be clarified, but also likely need a new approach that reflects shared responsibility across users, producers, and across regulatory agencies A = Ambiguous and B = Broken at the written law level

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views FDA Program Administration Apart from those regulatory issues, the subgroup has also identified an issue with how the agency administers the law. There is presently a weakness in the agency coordination of policymaking with regard to HIT software, and especially including mobile medical apps. This weakness includes:  inconsistencies in information shared with individual companies, and  unclear guidance more generally, including the lack of a final guidance on mobile medical apps.

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views ONC issues where attention needed ItemIssue: A or B Description of challenge Mandatory elements BONC program does not include capability in law enforcement, nor its programs framed with mandates where necessary Assurance of Safe Configuration ASafety depends on appropriate post-installation configuration. No means to educate or require compliance with documented and evolving best practices A = Ambiguous and B = Broken at the written law level

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views FCC issues where attention needed ItemIssue: A or B Description of challenge Post-installation Surveillance ASpectrum management and identification, diagnosing, and resolving wireless co-existence/EMC problems that affect HIT and medical device performance (in healthcare facilities and mHealth environments) A = Ambiguous and B = Broken at the written law level

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views Cross agency issues where attention needed ItemDescription of challenge Reporting of safety issues FDA/FCC/ONC The need to aggregate data across all three agencies to understand what the data are really telling us. What is the role for AHRQ and their common formats for adverse events reporting? Coverage of interoperability issues FDA/ONC Unclear and incomplete responsibility. Assumption that ONC does regulate HIT/medical device interface and FDA regulates med device/med device interface. But same med device (e.g. infusion pump) could be installed in either configuration. Which agency would receive report of “pump-server-HIT equipment-wireless infrastructure-EHR” related adverse event? Who is responsible for resolving? FCC/FDA reviewFCC and FDA do not coordinate their review processes (equipment authorization program and premarket review) to ensure they are consistent FCC/FDA conformity assessment Incomplete/missing clinically focused wireless conformity assessment tools that would facilitate safety and co-existence analysis

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views Bigger Picture Whether collectively the regulatory scheme in totality: 1. Fails to address some particular safety risk 2. Is too costly in relation to the risks it is designed to reduce; not scalable give pace/breadth of innovation. 3. Is demonstrably too burdensome on innovation, apart from imposing costs We agreed not to get into politics or philosophy but instead stick to evidence driven policy.

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views Innovation Department FDA ONC FCC

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views What elements of regulation are required to drive/encourage/allow HIT and mobile medical applications to achieve their full value in reducing medical errors, making crucial patient-specific health information available when and where needed, and report, track and aggregate patient data within and across organizations? What elements need to be avoided because they impede/frustrate/discourage innovation?

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views Safety and HIT Critical distinction between causing and allowing, or incompletely preventing harm, particularly in light of intervening learned intermediaries (clinicians, family members, patients). “So far, the evidence we have doesn’t suggest that health information technology is a significant factor in safety events,” said Jodi Daniel, director of ONC’s office of policy and planning. “That said, we’re very interested in understanding where there may be a correlation and how to mitigate risks that do occur.” Doubtless opportunity to reduce harms, which we should accelerate. Inducing regulatory-based delay here may paradoxically be viewed as ‘causing’ harm.

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views Additional context for HIT safety and regulation Cigarettes 1 in 5 deaths, sold in grocery stores Regulatory posture – graphic warnings Automobiles 10 million ‘crashes’ > 30 thousand fatalities #1 cause of death in age < 34 Regulatory posture – operator licensure NHTSA safety ratings, post-market surveillance

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views Additional context for HIT safety and regulation Hospitals 1 in 3 / 1 in 5 / 1 in 7 harmed ~ 200,000 preventable deaths Regulatory posture – complex web HIT: more an objective reporter or a potential solution than proximate cause!

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views What fuels innovation? Identification of unmet needs Novel capabilities that address the need, iteration on potential solutions with real-world feedback, and continuous improvement An actual market

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views Identification of unmet needs Innovators require access to the pain points of the current process – in this setting, it is essential that the limitations of existing systems be transparently available – not just for safety considerations as has been previously described, but also publicly available as persistently evolving user requirements for the innovator. Transparency of limitations/errors/failures is a prerequisite for innovation (and it also aligns with safety concerns).

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views Novel capabilities, feedback, and continuous improvement Rapid-cycle feedback is essential for innovation, and the specific use-case of health care demands timeliness for both feedback and iterative change of product offerings. Timely and transparent reporting of limitations/errors/failures is a prerequisite for innovation (and it also aligns with safety concerns). Process capabilities of the vendors (design controls, timely responsiveness in CAPA systems, verification and validation capabilities are essential (and aligned with safety concerns)

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views Aligned Incentives by the Purchaser For innovation to succeed, the ‘solution’ can not be arbitrarily impeded from entering the market (via monopolist behavior, excessive switching costs, constructed incompatibilities, etc.) Standards-based interoperability is a prerequisite for innovation (and it also aligns with safety concerns)

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views So, what regulatory elements are essential to promote innovation, protect patient safety, and avoid regulatory duplication? Timely, public and detailed reporting of limitations/errors/failures (notably and specifically including the current unmet need of a tool kit for automatic reporting and searching/analyzing and identifying trends within such a collection of public reports). Standards-based vendor qualification (as opposed to product certification) Requirement for meaningful, functional, open, standards-based interoperability.

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views CE Mark Process CE mark is not a quality mark, nor it is a symbol intended for consumer assurance. CE mark acts as a visible sign to let member state authorities know that a product is in compliance with the applicable directive(s). All manufacturers are required to affix a CE mark to products governed by the European Directives.

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views FDA vs. European Regulatory Timelines 510(k) vs. CE mark regulator y timelines PMA vs. CE mark regulator y timelines FDA Impact on U.S. medIcal technology InnovatIon: A Survey of Over 200 Medical Technology Companies November 2010

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views CE Mark Process (Continuation) There are four classes of products: Class I, IIa, IIb and III. How classification is determined: Device intended use Active vs. non active functionality Device’s duration of contact with patient Degree of invasiveness Part of body contacted by device

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views CE Mark Process (Continuation) In order to determine a device classification, the manufacturer(*) needs to use Annex IX (classification criteria) of MDD 93/42/EEC and follow the 18 rules to determine the appropriate classification of product. (*) Manufacturer: Entity responsible for design and that will take any regulatory responsibility over the product. The manufacturer will be identified as part of the product label.

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views CE Mark Process (Continuation)  Class I: Low Risk – Non-sterile, non-measurement devices. Class I: Sterile, Measurement devices.  Class IIa – Medium Risk – Short invasive devices.  Class IIb – High Risk – Longer term invasive devices.  Class III – Highest risk – Active implantable devices.

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views CE Mark Process (Continuation) If a manufacturer is a Class I – Sterile/measurement, IIa, II b or III, they must implement a quality management system and a notified body needs to be involved. If a manufacturer is a Class I – Non-Sterile/Non- measurement device, they can self-certify against the requirements of the applicable Medical device Directives (MDD).

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views CE Mark Process (Continuation) Self-certification for products with the least mount of risk that are not sterile and do not measure anything can be completed by making a declaration of compliance with the Medical Device Directive (MDD) and placing the CE mark on the product. No involvement of notified body is required. Self-certification means that you DECLARE (on a document) that the product you are selling in Europe complies with MDD and company representatives sign/agree with this document.

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views Class 1 Medical Devices

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views CE Mark Process (Continuation) For Class I sterile, measurement devices, where the product is either sterile or measures something, then a notified body involvement is required. Most companies go through a full QA process by obtaining ISO (*), which is certified by a notified body. (*) ISO13485 is similar to the quality system that FDA requires plus a few additional requirements needed in Europe.

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views CE Mark Process (Continuation) The EU directives require for manufacturers to be “compliant” to a quality management system prior to issuance of the CE mark, while FDA clearance through the 510(k) does not. FDA inspects to 21CFR sometime after the 510(k) clearance is given and devices are on the market, but this may occur many years afterwards.

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views One view... Defining a predictable, reasonable process for low risk medical products (Class I), similar to the EU directives CE mark, may prevent delays in access to low-risk innovative patient-centered medical technologies solutions for the continuous improvement of patient care.

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views What about “local” modification of HIT? Endless permutations and combinations of well-meaning, innovative, ‘tinkering’ HIT, like other tools in the practice of medicine, may have its greatest value when the knowledgeable, experienced, and inspired practitioner is free to alter, adjust, enhance, modify, tailor, tinker, etc. This process, also like the practice of medicine, benefits from (very) local, as opposed to central, review, with programmatic escalation. Installation Integration Modification Updates Tailoring Patches Enhancements Fixes, etc…

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views So, what regulatory elements are essential…? Timely, public and detailed reporting of limitations/errors/failures (notably and specifically including the current unmet need of a tool kit for automatic reporting and searching/analyzing and identifying trends within such a collection of public reports). Standards-based vendor qualification similar to CE Class I (as opposed to product certification). Requirement for meaningful, functional, open, standards-based interoperability. Local review of local modifications (with transparent reporting and escalation).

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views Some important potential specifics (AM-S) To enable/facilitate a lighter regulatory touch: Transparency - IP should be protected, but all documentation on process/data format, etc. should be provided Open Feedback Platform - an online rating platform whereby identified users can provide feedback, make suggestions for bug fixes, report issues, etc. (sort of like iTunes or Amazon rating) Data Sharing/Transparency - in particular, device manufacturers who collect electronic data from devices, which is then used in/displayed by MDDS platforms (Most diabetes device manufacturers collect this data, but they do not let FDA access the raw data files. As a result, it's difficult to assess how many device failures/malfunctions actually occur, because very few actual AEs are reported via Medwatch.) Standard Data Formats - all data should be exportable or downloadable in a standard data format. Open APIs - All apps/MDDS components must provide open APIs, so that other developers can create mechanisms for accessing/downloading data. Operating System Usability - all applications requiring desktop use would need to be accessible via either Windows or Apple platforms. Other platforms could be considered as market forces dictate

Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views In exchange for the above, manufacturers would be permitted to: Market/release HIT and MDDS products without prior approval Conduct rapid iterations/modifications to device software/MDDS if the software modifications do not affect the platform that operates the device but rather one of the data recording components of the device (i.e. "event" marking on insulin pumps, CGMs and accompanying mobile apps.) Competition could be based on consumer ratings - would be able to use consumer ratings, customer satisfaction elements from the online feedback platform within marketing materials. Some important potential specifics (AM-S)