Toward Stimulating a Broader View
36
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
description
Toward Stimulating a Broader View. (not approved, barely proof-read) Draft 07/07/13. From the Federal Register. - PowerPoint PPT Presentation
Transcript of Toward Stimulating a Broader View
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 RegisterUnder 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 weekDiscussion 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
Item Issue:A or B
Description of challenge
Wellness/disease borderline
A & B FDA needs to explain how to discern disease related claims from wellness, and needs to deregulate low risk disease related claims
Accessory issues A & B FDA 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 software A FDA needs to explain which forms of clinical decision support software it regulates
Software modularization
A FDA 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
Item Issue:A or B
Description of challenge
Intended use issues
A FDA 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
A FDA needs to explain how the quality system requirements and facility registration apply to manufacturing of standalone software
Premarket requirements for interoperable devices
A FDA 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 & B Responsibilities 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
Lauren Fifield
The converse of this is the part vs. whole concept: functionality within a piece of software/platform/technology also needs to be accounted for--not ALL parts of an EHR bear a risk of harm; as an example, how can the FDA regulate CDS within an EHR and not require regulation of the functionality that should be driven by market forces?
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
Item Issue:A or B
Description of challenge
Mandatory elements
B ONC program does not include capability in law enforcement, nor its programs framed with mandates where necessary
Assurance of Safe Configuration
A Safety 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
Item Issue:A or B
Description of challenge
Post-installation Surveillance
A Spectrum 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
Item Description of challenge
Reporting of safety issuesFDA/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 issuesFDA/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 review FCC 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
Lauren Fifield
also, given the patient safety act of 2005 how does AHRQ fit into this? Also, for apps and tools that aren't yet regulated by the FDA/ONC/FCC and where we determine that post-market surveillance/enforcement/etc is necessary, why can't FTC play a role?
Lauren Fifield
AHRQ is developing common formats for adverse event reporting...they should likely develop formats or be part of that development for things like interop issues
Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views
Bigger PictureWhether collectively the regulatory scheme in totality:1. Fails to address some particular safety risk2. 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 costsWe agreed not to get into politics or philosophy but instead stick to evidence driven policy.
Lauren Fifield
I might add one or two points to say:-Current framework is not financially scalable or flexible enough (part of #2?)-Current system was also created before payment reform and need for rapid evolution of care delivery on the back of HIT
Work product for review and discussion by the FDASIA Regulation Subgroup; May not reflect the subgroup’s views
Innovation Department
FDA ONCFCC
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.”
• http://www.bloomberg.com/news/2013-06-25/digital-health-records-risks-emerge-as-deaths-blamed-on-systems.html
• Doubtless opportunity to reduce harms, which we should accelerate. Inducing regulatory-based delay here may paradoxically be viewed as ‘causing’ harm.
Lauren Fifield
like this
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 deathsRegulatory posture – complex webHIT: 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)
Lauren Fifield
I think it'd also be helpful to mention that there are key differences between the ambulatory and inpatient markets--the purchaser, needs, budget, etc. I think the ambulatory market is in a much better position to connect the needs of the user with the technology purchased because end-user and purchaser are generally the same in that environment. However, feedback loops and consistent reporting is more likely to be seen in the process-driven environment of a health system or hospital. To correct for these and ensure both innovation and the neccesary feedback/reporting, end users in the inpatient setting need to be better addressed and consistent feedback/reporting in the ambulatory setting need to be established.
Lauren Fifield
another thing to consider is the role of incentives and the EHR donation safe harbor--these types of payments have further driven a wedge between the purchaser and end-user, which I think is detrimental to innovation and also doesn't cultivate a market where purchasers are the users who are likely to purchase solutions FOR safety and report adverse events to improve the system
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
regulatory
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 13485 (*), 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.
InstallationIntegrationModificationUpdates Tailoring
PatchesEnhancementsFixes, 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)
