Keeping pace with the ever-changing life sciences industry, Morrison Foerster stays on top of the trends and political, legal, and economic drivers to support striking the balance between innovative discovery and purposeful business planning to assure our clients continued success. MoFo Life Sciences shares timely legal and business insights and in-depth analyses on trends and the complex technologies at the heart of the global pharmaceutical, biotechnology, diagnostics, medical devices, digital health, and AgTech fields.Learn more about our <a href="https://www.mofo.com/capabilities/life-sciences-healthcare" target="_self">Life Sciences practice</a>.<h2 dir="ltr">ABOUT MORRISON FOERSTER</h2>Morrison Foerster is a leading global law firm that transforms complexity into advantage for its clients. Our clients include some of the largest financial institutions, banks, consulting and accounting firms, and Fortune 100, technology, and life sciences companies. Highlighting the firm’s commitment to client service, leadership in market-changing deals and impact litigation, and values-based culture, Morrison Foerster has been repeatedly recognized as one of the top 10 firms on The American Lawyer’s A-List. Year after year, the firm receives significant recognition from Chambers and The Legal 500 across their various guides, including Global, USA, Asia‑Pacific, Europe, UK, Latin America, and FinTech Legal. Our lawyers passionately care about delivering legal excellence while living our values. Morrison Foerster has a long-standing commitment to creating a culture that respects and celebrates differences, while providing an inclusive environment. The firm has achieved Mansfield Certification Plus since 2018 as a result of successfully reaching at least 30 percent women, communities of color, and LGBTQ+ lawyer representation in a notable number of current leadership roles and committees. The firm also has a long history of commitment to the community and society through providing pro bono legal services, including litigating for civil rights and civil liberties, improving public education and fostering the wellbeing of children, advocating for veterans, promoting international human rights, enforcing the right to asylum, and safeguarding the environment.

Social

Search

Subscribe

Life Sciences and Healthcare Group

Life Sciences Podcast

Patent Counseling + Prosecution

FDA Regulatory + Life Sciences Compliance

FDA + Healthcare Regulatory and Compliance 

Life Sciences Transactions + Licensing

Resources

Editors

230315-new-mofo-life-sciences-logo.jpg

Dr. Meghan Poon counsels clients on patent preparation and prosecution, portfolio strategy, and IP due diligence in the areas of biotechnology and biologics. She has significant experience in diverse technologies including antibodies, cell therapies, gene therapies, diagnostics, and gene-edited plants. She represents clients ranging from large international pharmaceutical companies to midsized companies, startups, and universities.Meghan has filed numerous Patent Term Extension applications to secure additional term for her clients’ patents, which cover FDA-approved products. In addition, Meghan has extensive experience addressing complex obviousness-double patenting and subject matter eligibility issues impacting her clients’ patent portfolios. Meghan also represents clients in both investor-side and target-side due diligence, in deals from seed funding to initial public offerings.Prior to law school, Meghan attended graduate school at the University of California, Los Angeles, where she received a Ph.D. in biological chemistry based on her work on protein-protein and protein-DNA interactions at a molecular level. Meghan is the author of several scientific publications and has presented her research at international conferences.Meghan received her J.D. from the University of Southern California Law School and spent a year as a visiting student at Santa Clara University, where she focused on intellectual property.

poon_meghan_blog_150x150.png

poon_meghan_common_640x280.jpg

poon_meghan_heroretina_2700x1160.jpg

poon_meghan_mobileretina_750x1040.jpg

poon_meghan_social_600x600.jpg

Partner

Morrison Foerster's patent prosecution and patent strategy team is highly qualified with more than 100 advanced degrees and multilingual capabilities.

With 80+ Ph.D.s, more than 100 advanced degrees, and multi-lingual capabilities, including Chinese and German, we offer clients around the world a patent prosecution and counseling practice that is unrivaled in its depth of industry and technical experience.

Patent Strategy + Prosecution

Patent Prosecution | Patent Firm

Band 1: Intellectual Property: Patent Prosecution, California

Tier 1: Patent Strategy & Management

Recommended: Patent Prosecution

Patent Strategy Firm Of The Year

 Intellectual Property: Patents: Prosecution

Recommended for Patent Prosecution in California and DC Metro Area

Highly Recommended: Patent Prosecution, California

Patent Prosecution, US 

Dr. Meghan Poon counsels clients on patent preparation and prosecution, portfolio strategy, and IP due diligence in the areas of biotechnology and biologics. She has significant experience in diverse technologies including antibodies, cell therapies, gene therapies, diagnostics, and gene-edited plants.

Meghan Poon

Wolfgang advises clients on contentious and non-contentious matters involving their most valuable intellectual property assets in life sciences, digital, and high-tech industries.His subjects of focus include research and development collaborations, complex licensing agreements, and other technology transactions, as well as know-how protection strategies, and employee invention law. He also has substantial experience in litigating patents, trademarks, and other intellectual property assets, often in a multijurisdictional context. In addition, Wolfgang and his team frequently clear trademarks and ad campaigns and prosecute trademark applications.Wolfgang is co-editor of our <a href="https://lifesciences.mofo.com/" dir="ltr" target="_blank">MoFo Life Sciences Blog</a>.Wolfgang is a partner of Morrison Foerster based in our German office in Berlin.<h4 dir="ltr">Representative Transactional Matters</h4><ul dir="ltr"><li>U.S.-based BioTech fund on various research collaborations and other transactions with German start-ups or research institutions.</li><li>Negotiate multimillion-euro strategic partnership between two AgTech leaders concerning the development and commercialization of pest-resistant transgenic traits.</li><li>Craft global multi-million collaboration regarding AI-powered robotic MaaS.</li><li>UK-based digital health company on product roll-out of RPM applications in Germany; coordinate international expansion.</li><li>Advise numerous German start-ups on their U.S. expansion.</li><li>Draft diverse global patent and know-how license agreements in the areas of AgTech and life sciences—including gene licensing and licensing of genome editing technologies (e.g., CRISPR)—and medical devices; draft correlating supply and distribution agreements.</li><li>Structure IP rights in connection with joint ventures and other M&A transactions, including the carve-out of a patent-heavy semiconductor business comprising nine jurisdictions into a German–U.S. joint venture.</li><li dir="ltr">Advise on government-funded, multi-partner R&D projects and/or R&D projects with academic institutions, as well as on employee invention law.</li></ul><h4 dir="ltr">Representative Contentious IP Matters</h4><ul dir="ltr"><li>Lead counsel in an international dispute between software companies on rights and obligations following termination of a multi-million licensing and distribution arrangement; coordinate local counsel.</li><li>Defend Japanese chip manufacturer in high-profile SEP-litigation; advise on global settlement arrangement.</li><li>Represent leading internet retailer in patent infringement and concurrent invalidity proceedings in the context of a multijurisdictional dispute concerning touch-screen technology.</li><li>Represent diverse pharmaceutical and life sciences companies in national and cross-border patent infringement proceedings and other technology-related disputes, including preliminary injunctions as well as pre‑trial discovery and inspection proceedings, concerning, inter alia, drug-coating technologies, toner cartridges, medicinal gases, transgenic plants, and vaccines.</li><li dir="ltr">Conduct trademark, copyright, and false advertising litigation, including, most notably, a high-profile trademark litigation for a German bank, and a nine-country cross-border trademark litigation involving a famous pharmaceutical brand.</li></ul>

Dr. Wolfgang Schönig berät Mandanten zum Schutz des geistigen Eigentums sowohl in streitigen als auch nichtstreitigen Angelegenheiten, mit einem besonderen Fokus auf die IP-rechtliche Beratung von Unternehmen aus den Bereichen Life Sciences, Digitalwirtschaft und High-Tech.Zu seinen Beratungsschwerpunkten gehören Forschungs- und Entwicklungskooperationen, komplexe Lizenzvertragsgestaltungen und andereTechnologie-Transaktionen, sowie Know-how-Schutz-Strategien und das Arbeitnehmererfinderrecht. Er verfügt zudem über umfangreiche Prozesserfahrung zur Durchsetzung von Patenten, Marken- und anderen IP-Rechten, häufig auch in einem grenzüberschreitenden Kontext. Darüber hinaus bewertet Dr. Wolfgang Schönig zusammen mit seinem Team regelmäßig die Rechtskonformität von Werbekampagnen, prüft die Verfügbarkeit von Marken und entwickelt entsprechende Anmeldestrategien.Dr. Wolfgang Schönig ist Co-Editor des Life Sciences Blogs von Morrison Foerster.Er hat seinen Doktortitel an der Heinrich-Heine-Universität Düsseldorf und seinen LL.M. an der Fordham School of Law in New York erworben, jeweils mit Schwerpunkt im gewerblichen Rechtsschutz. Seinen MBA-Abschluss erhielt er von der European University in Barcelona.Dr. Wolfgang Schönig ist Partner des deutschen Büros von Morrison Foerster in Berlin.<h4 dir="ltr">Repräsentative Transaktionen</h4><ul><li dir="ltr">BioTech-Fonds mit Sitz in den USA bei verschiedenen Forschungskooperationen und anderen Transaktionen mit deutschen Start-ups oder Forschungseinrichtungen</li><li dir="ltr">Verhandlung einer hochvolumigen strategischen Partnerschaft zwischen zwei Technologieführern im Bereich Crop Science betreffend der Entwicklung und Kommerzialisierung von bestimmten Resistenzen</li><li dir="ltr">Gestaltung einer globalen Multi-Millionen-Zusammenarbeit für KI-gestützte Roboter</li><li dir="ltr">Ein in Großbritannien ansässiges Unternehmen für digitale Gesundheit bei der Markteinführung von RPM-Anwendungen in Deutschland; Koordination der internationalen Expansion</li><li dir="ltr">Beratung zahlreicher deutscher Start-ups bei deren US-Expansion</li><li dir="ltr">Strukturierung und Verhandlung diverser Patent- und Know-How-Lizenzen in den Bereichen Ag Tech und Life Sciences – einschließlich Fragen zu genome editing wie CRISPR-Medizingeräte, sowie Gestaltung von Softwarelizenzverträgen und Erstellung korrespondierender Liefer- und Vertriebsvereinbarungen</li><li dir="ltr">Strukturierung von IP-Rechten im Zusammenhang mit Joint Ventures und anderen M&A-Transaktionen, darunter die Koordination eines neun Länder umfassenden IP Carve-Outs im Rahmen eines Halbleiter-JVs</li><li dir="ltr">Beratung zu staatlich geförderten Multi-Partner F&E-Projekten und/oder F&E-Projekten mit akademischen Einrichtungen sowie zum Arbeitnehmererfindungsrecht</li></ul><h4 dir="ltr">Repräsentative IP-Streitigkeiten</h4><ul><li dir="ltr">Lead Counsel in einem internationalen Rechtsstreit zwischen Softwareunternehmen über Rechte und Pflichten nach Beendigung einer millionenschweren Lizenz- und Vertriebsvereinbarung; Koordinierung der lokalen Anwälte</li><li dir="ltr">Verteidigung eines japanischen Chipherstellers in einem prominenten Streitfall bezüglich Standardessentieller Patente (SEP); Beratung zu einer globalen Vergleichsregelung</li><li dir="ltr">Verteidigung einer führenden Internetplattform gegen Ansprüche eines Patenttrolls wegen vermeintlicher Verletzung von Patent bezüglich Touchscreen-Technologie sowie korrespondierende US-Streitigkeiten</li><li dir="ltr">Vertretung von Pharma- und Life Science-Unternehmen in nationalen und grenzüberschreitenden Patentverletzungsverfahren und anderen technologiebezogenen Streitigkeiten, einschließlich einstweiliger Verfügungsverfahren und vorprozessualer Beweissicherungs- und Besichtigungsverfahren, unter anderem in Bezug auf Arzneimittelbeschichtungstechnologien, Tonerkartuschen, medizinische Gase, transgene Pflanzen und Impfstoffe</li></ul>

schonig_wolfgang_blog_150x150.png

schonig_wolfgang_common_640x280.jpg

schonig_wolfgang_heroretina_2700x1160.jpg

schonig_wolfgang_mobileretina_750x1040.jpg

schonig_wolfgang_social_600x600.jpg

Our life sciences and healthcare clients, from emerging innovation drivers to iconic brands, rely on our unrivaled depth of knowledge and technological experien

Life Sciences: IP/Patent Litigation

Life Sciences

Global: Life Sciences

Asia-Pacific Region: Life Sciences

Healthcare: Life Sciences

China Healthcare and Life Sciences: Foreign Firms

US: Biotechnology Law

Japan: Life Sciences

China: Life Sciences: International Law Firm

Wolfgang Schönig is a partner of Morrison Foerster (International) LLP based in our German office in Berlin. His practice specialty is advising on IP aspects relative to transactions in, among others, the life sciences, AgTech and pharmaceuticals industry, as well as legal representation in IP disputes. Wolfgang is specialized in research and development collaborations, complex licensing agreements, technology acquisitions, know-how protection strategies, and employee invention law.

Wolfgang Schönig focuses his practice on IP aspects relative to transactions in the digital, telecoms, high tech, life sciences, and pharmaceuticals industry, as well as legal representation in IP disputes.

Wolfgang Schönig advises clients on IP aspects relating to transactions in, among others, the life sciences, AgTech and pharmaceuticals industry, as well as legal representation in IP disputes. His additional focus areas include research and development collaborations, complex licensing agreements, technology acquisitions, know-how protection strategies, and employee invention law.

Wolfgang Schönig

favicon.ico

favicon-16x16.png

favicon-32x32.png

apple-touch-icon.png

MoFo Favicons

MoFo Life Sciences shares timely legal and business insights and in-depth analyses on trends and the complex technologies at the heart of the global pharmaceutical, biotechnology, diagnostics, medical devices, digital health, and AgTech fields.

life-sciences-featured-image.jpg

life-sciences-featured-image

Announcements

Welcome to Mofo Life Sciences

Blog - Terms of Use

Cookies

Blog - Privacy Policy

Blog - Blog Disclaimer

Blog - Attorney Advertising

morrison-foerster-blog-logo.png

Brings together legal insights and in-depth analyses on trends and complex issues shaping the global technology industry.

MoFo Tech Blog

MOFO TECH

Equips our clients with the most up-to-date and relevant information on employment and labor law issues.

Employment Law Commentary

EMPLOYMENT LAW COMMENTARY

Stay on top of emerging issues and stay informed of developments related to the law and business of social media.

Socially Aware

SOCIALLY AWARE

In-depth analysis of developments and trends impacting government contracting.

Government Contracts Insights Blog

GOVERNMENT CONTRACTS INSIGHTS

Provides insights and reports on the most current class actions lawsuits and product liability issues that affect consumer-facing companies.

Class Dismissed Blog

CLASS DISMISSED

MoFo Life Sciences

  Linkedin

MoFo LinkedIN

Life Sciences Blog - RSS

Stay Connected

Never miss a post from MoFo Life Sciences. Enter your email below to stay up-to-date.

Because No One is Immune to the Law

Morrison Foerster - Footer

Blogs -  Home Button

Home

Blog - Topics

Agtech

Antitrust

Asia

Bioinformatics

Biotech

Blockchain

Cell + Gene Therapy

CFIUS

Corporate + Venture Capital

COVID-19

Data Analytics

Digital Health

Employment

European Union

Financing

Global

Healthcare

Intellectual Property

Licensing + Commercial

Litigation

Medical Devices + Diagnostics

Pharma

Privacy + Data Security

Product Liability + Class Action

Rare Disease

Regulatory

Startup

United Kingdom

United States

Topics

Blog - Editors

Blog - About

About

Blog - Subscribe

Meghan McLean Poon Ph.D.

More

In Patent Prosecution, You Have the Right to Remain Silent. Anything You Say Can and Will Be Used Against You in the Court of Law

Federal Circuit Clarifies Requirements for Prior Art Under Pre-AIA 35 U.S.C. § 102(e)

AI Agent as a Service in Medtech: Key Considerations for Commercial Contracts

HHS Secretary to FDA: Consider Elimination of GRAS Self-affirmation Pathway

Federal Circuit Clarifies Patent Term Extension Calculation for Reissue Patents

LinkedIN

By now you are likely aware of the new safe harbor provisions of the federal anti-kickback statute (AKS), which the U.S. Office of Inspector General (OIG) finalized as of January 19, 2021. Among other changes to the AKS regulations, OIG created new safe harbors for: (i) value-based arrangements and (ii) arrangements related to the Centers for Medicare & Medicaid Services (CMS) sponsored model arrangements and modeled patient incentives. These new safe harbors emphasize the idea of value-based care and involve some level of risk sharing between entities in the provision of health care or services adjacent to health care.Prior to the promulgation of these new safe harbors, parties found it difficult to creatively structure arrangements to neatly fit into an AKS safe harbor. However, since the beginning of the new year, and the finalization of the new safe harbors, we have witnessed a sharp uptick in these types of value-based arrangements, as health care providers, medical device companies, and insurers attempt to get more creative with partnerships and their delivery of health care services. Accordingly, in order to take advantage of the more flexible pricing structures that these safe harbors allow, we expect to continue to see these types of arrangements increase.While the CMS-sponsored model safe harbor clearly maps out specific models adopted by CMS, the value-based arrangement safe harbors allow parties to innovate in their relationships to provide care that aligns with a “value-based purpose.” Under the AKS safe harbor language, value-based purposes include: coordinating and managing the care of a target patient population; improving the quality of care for a target patient population; appropriately reducing the costs to or growth in expenditures of payors without reducing the quality of care for a target population; and transitioning from health care delivery and payment mechanisms based on the volume of items and services provided to mechanisms based on the quality of care and control of costs of care for a target patient population.Notably, OIG prohibits medical device manufacturers from utilizing two of the new value-based safe harbors: value-based arrangements with substantial downside risk and value-based arrangements with full financial risk safe harbors. However, there are still two additional value-based safe harbors that medical device manufacturers may employ. Specifically, medical device manufacturers can utilize: (i) the safe harbor for care coordination arrangement to improve quality, health outcomes, efficiency, and patient engagement; and (ii) the safe harbor for support to improve quality, health outcomes and efficiency.The care coordination safe harbor focuses on digital health tools. The AKS regulations define digital health tools as “hardware, software, or services that electronically capture, transmit, aggregate, or analyze data and that are used for the purpose of coordinating and managing care; such term includes any internet or other connectivity service that is necessary and used to enable the operation of the item or service for that purpose.” Effectively, this safe harbor allows a company wider flexibility in structuring arrangements, particularly for new products that may assist health care providers with care coordination and provide higher quality health care services at lower costs, particularly where these products may be untested and could therefore benefit from a risk-sharing arrangement until the true impact and value of the products becomes known.For the new AKS safe harbors pertaining to substantial downside and full financial risk, we expect to see insurance companies and various types of health care providers employ new digital health tools when providing health care services. These companies will test the tools against patient populations to examine whether the tools increase the quality of health care services provided while simultaneously lowering health care costs. When risk sharing, both sides have skin in the game to incentivize providing high-quality care at lower costs.With the influx of innovation and new health care delivery models, it is important to note that all of the new AKS value-based safe harbors contain guardrails to ensure that health care providers and ancillary companies enter these arrangements for a value-based purpose; health care providers do not ration medically necessary care; parties do not prevent health care providers from making decisions in the best interests of their patients; parties do not limit patients’ preferences for different practitioners, providers, or suppliers; and that arrangements have clear outcome-based benchmarks and measures for evaluating the value-based arrangements.

healthcare.jpg

Is 2021 the Value-Based and Shared Savings Revolution?

Is 2021 the Value-Based and Shared Savings Revolution?

1023224308

By now you are likely aware of the new safe harbor provisions of the federal anti-kickback statute (AKS), which the U.S. Office of Inspector General (OIG) final

In Part 6 of our <a href="https://lifesciences.mofo.com/topics/Software-as-a-Medical-Device-in-Europe--New-Regulatory-Regime-About-to-Enter-into-Force--Part-1-of-6.html?utm_source=linkedin_elevate&utm_medium=social" target="_blank">series of consecutive articles</a> on the reformed regulatory framework under the <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02017R0745-20200424" target="_blank">EU Medical Device Regulation 2017/745</a> (“MDR”), which will govern medical devices software (“MDSW”) in the EU, we turn to the transition periods certain MDSW can benefit from before being required to fully comply with the MDR.Transitional periods are provided in Article 120 MDR. In part due to the COVID-19 pandemic, the original text of Article 120 MDR has been corrected by two corrigenda (<a target="_blank" href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32017R0746R%2802%29">I</a>, <a target="_blank" href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32017R0746R%2803%29">II</a>) and another <a target="_blank" href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2020.130.01.0018.01.ENG">Regulation</a> to avoid additional burdens to stakeholders and impasses in the supply of medical devices. The changes introduced by these amendments are twofold: On the one hand, the scope of the existing transitional periods was substantially changed and now includes more devices. On the other hand, the MDR now reflects the pushed-back applicability dates of the MDR and their influence on the transitional periods.Due to the many amendments, however, the European legislator missed its aim to lay down clear and legible transitional rules. Therefore, the following article will decipher Article 120 MDR and provide an overview, which rules have to be observed when, as well as the prerequisites MDSW has to meet in order to benefit from the grace periods.<h4>1. INTRODUCTION: THE TERMINOLOGY OF ARTICLE 120 MDR</h4>The various transitional periods granted by Article 120 MDR allow for extended “placing on the market,” “making available on the market,” and “putting into service” of certain legacy MDSW, i.e., MDSW that was in compliance with the provisions of the current <a href="https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CONSLEG:1993L0042:20071011:en:PDF" target="_blank">EU Medical Device Directive 93/42/EEC</a> (as amended by Directive 2007/47/EC – “MDD”). Other than with physical medical devices, it can be challenging to determine when these actions take place. It is thus worthwhile to take a closer look at their definitions under the MDR.Placing on the market means the first making available of a device, other than an investigational device, on the EU market (Article 2 (28) MDR). It is subject to an ongoing debate whether MDSW is placed on the market as soon as it is offered for download through a website or an App Store or whether every license or access key to a MDSW granted to a user is placed on the market upon issuance. The latter option seems favorable due to the underlying rationale of the MDR. Most of the MDR provisions, including the transitional rules, were designed with physical medical devices in mind, and it is therefore common understanding that the placing on the market applies separately to each individual device. Translated to MDSW, this means that every license or access key will only be considered placed on the market once it is issued to the user.Making available on the market means any supply of a device, other than an investigational device, for distribution, consumption, or use on the EU market in the course of a commercial activity, whether in return for payment or free of charge (Article 2 (27) MDR). Putting into service means the stage at which a device, other than an investigational device, has been made available to the final user as being ready for use on the EU market for the first time for its intended purpose (Article 2 (29) MDR). Following the placing on the market through issuance of a license or access key to MDSW, it is then made available through the download by a user and put into service through its installation. These modalities therefore cover the maintenance of licenses to MDSW that were already granted to the user.It must be mentioned that while some notified bodies back these conclusions, they are not set in stone, as courts have not yet decided on these issues.<h4>2. TRANSITIONAL PERIODS FOR UP-CLASSIFIED MDSW</h4>In <a target="_blank" href="https://lifesciences.mofo.com/topics/Software-as-Medical-Device-in-Europe-New-Reg-Regime-to-Enter-into-Force-Part-3.html">Part 3</a> of this series, we discussed that it is to be expected that many MDSW that are currently classified in Class I under the MDD will be up-classified to Class IIa or higher under the MDR regime (“Up-classified MDSW”). Such MDSW will benefit from the transitional periods of the MDR in two ways. First, new licenses and access keys to Up-classified MDSW may be granted until May 26, 2024 (Article 120 (3) MDR). Second, licenses and access keys granted until May 26, 2024, may be maintained until May 26, 2025 (Article 120 (4) MDR), i.e., users may use, download, and install Up-classified MDSW that they already purchased.a. Requirements for granting new licenses to Up-classified MDSWFor the aforementioned transitional periods to apply, the following requirements have to be met (see <a target="_blank" href="https://ec.europa.eu/docsroom/documents/40324/attachments/1/translations/en/renditions/native">MDCG 2020-2</a> Guidance for further instructions; please note that the dates mentioned therein do not reflect the dates of the current version of the MDR):<ul><li>The MDSW needs to continue to comply with the MDD.</li></ul><ul><li>A valid Declaration of Conformity (“DoC”) complying with Annex VII of the MDD must be drawn before May 26, 2021. With the DoC, the manufacturer of the MDSW declares that it meets the relevant requirements of the MDD. Comprehensive instructions on the form, content, and handling of the DoC can be found in the MDCG 2020-2 Guidance, the <a target="_blank" href="https://eur-lex.europa.eu/legal-content/GA/TXT/?uri=CELEX:52016XC0726(02)">Blue Guide on the implementation of EU products rules 2016 (2016/C272/01)</a>, the standard EN ISO/IEC 17050-1/2, and the model declaration in Annex III of <a target="_blank" href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32008D0768">Decision No 768/2008/EC</a>.</li></ul><ul><li>The MDSW must not undergo significant changes to its design or intended purpose after May 26, 2021. It cannot be emphasized enough that this provision can have far‑reaching implications for the manufacturer’s ability to benefit from the transitional period, as it covers a lot of changes that could be considered desirable or, in the worst case, even mandatory changes. While the MDR does not define when a change is ‘significant,’ some meaningful guidance can be drawn from the <a target="_blank" href="https://ec.europa.eu/docsroom/documents/40301/attachments/1/translations/en/renditions/native">MDCG 2020-3 Guidance on Significant Changes</a> that leads the determination process through a series of flow charts. Additionally, the <a target="_blank" href="https://www.johner-institut.de/blog/wp-content/uploads/2015/11/Recommendation-NB-MED-2_5-2_Rec2_Reporting_of_design_changes_and_changes_of_the_quality.pdf">NB-MED Coordination on Council Directives 90/385/EEC, 93/42/EEC, and 98/79/EC</a> as well as the <a target="_blank" href="http://www.doks.nbog.eu/Doks/NBOG_BPG_2014_3.pdf">NBOG’s Best Practice Guide</a> should be considered. Following these guidelines, bug-fixes, security patches, and minor changes to non-critical parts of the user interface, such as spelling mistakes, will likely not be seen as significant. Vice-versa, changes to the intended user groups or changed indications, corrections of errors to minimize risks, changes to the user interface (like changing warning messages), or the use of a different runtime environment will likely be deemed significant (these examples are only for illustrative purposes and are not comprehensive).</li></ul>Any manufacturers of MDSW going this route are well advised to make themselves familiar with the guidance documents on significant changes. They should be aware that as MDSW by their very nature undergo a high volume of changes during their life cycle, it is likely that some of these changes could ultimately jeopardize the applicability of the transitional period.This risk is accelerated by the new <a target="_blank" href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32019L0770">EU Directive on Digital Content and Services 2019/770</a>, which contains a mandatory obligation to update digital products in order to keep them in conformity with the underlying contract (Article 8 (2)). These obligations also apply to products, for which the consumer “pays” for with personal data (Article 3 (1)). Depending on the nature of the MDSW and the respective contract, changes required in this context can be of a kind that would be seen as significant under the MDR. As the Member States of the EU have to transpose these rules into national laws until July 1, 2021, these obligations will be applicable to manufacturers of MDSW very soon.b. Maintaining existing licenses until May 26, 2025 (Article 120 (4) MDR)Designed as a sell-off provision for physical medical devices, Article 120 (4) MDR allows for the continued making available on the market and putting into service until May 26, 2025, of legacy medical devices that were placed on the market prior to May 26, 2024. For MDSW, this means that licenses and access keys that were already issued before May 26, 2024, can be maintained for another year. In this timeframe, the manufacturer can give users who have already obtained a license or access key further access to the MDSW, allow the respective installations, and use and offer technical support.<h4>3. TRANSITIONAL PERIODS FOR SAME-CLASS MDSW</h4>Legacy MDSW that is classified as Class I under the MDD and which will remain in Class I under the MDR regime (“Same-class MDSW”) will have limited transitional options. Only licenses or access keys to Same-class MDSW granted before May 26, 2021, may be maintained until May 26, 2025 (Article 120 (4) MDR), i.e., users may use, download, and install already obtained Same-class MDSW. This makes sense, as the main purpose for transitional periods must be found in the legislatures aim to avoid congestion of the bottleneck of certification, the notified bodies, and full compliance of Same-class MDSW with the MDR can be achieved by way of the continued possibility of self-certification of Class I devices, as we have shown in <a target="_blank" href="https://lifesciences.mofo.com/topics/Software-as-Medical-Device-in-Eu--New-Reg-Enter-into-Force--Part-2-of-6.html">Part 2</a> of this series.To be on the safe side, manufacturers of Same-class MDSW should also consider not changing their product as long as use of already-issued licenses and access keys are required before full compliance with the MDR.<h4>4. TRANSITIONAL PERIODS FOR HIGHER-CLASS MDSW</h4>Even though most MDSW under the MDD was classified in Class I, some software for high-risk medical scenarios was already in Classes IIa to III (“Higher-class MDSW”). For example, MDSW intended to image in vivo distribution of radiopharmaceuticals was in Class IIa and MDSW controlling emitters of ionizing radiation for therapeutic interventional radiology was in Class IIb (<a target="_blank" href="https://ec.europa.eu/docsroom/documents/17921/attachments/1/translations/en/renditions/native">MEDDEV 2.1/6 Guidance of July 2016</a>, p. 16).As Higher-class MDSW had to be certified by a notified body already under the MDD, the question whether new licenses and access keys may be granted depends on the continued validity of the certificate. Certificates to Higher-class MDSW certified prior to May 25, 2017, remain valid until the date indicated on the certificate.[1] Certificates to Higher-class MDSW certified after May 25, 2017, also remain valid until the indicated date but no longer than five years or until May 27, 2024, whichever is earlier. Accordingly, new licenses and access keys can be granted to customers as long as the MDSW certificate is valid but no longer than May 26, 2024 (Article 120 (2), (3) MDR).As with Up-classified MDSW, the following requirements have to be met for the transitional periods to apply.<ul><li>The MDSW needs to continue to comply with the MDD.</li></ul><ul><li>The MDSW must not undergo significant changes to its design or intended purpose after May 26, 2021.</li></ul>Any licenses and access keys granted in the described timeframe may be maintained until May 26, 2025 (Article 120 (4) MDR).<h4>5. MDR REQUIREMENTS TO BE MET DURING THE TRANSITIONAL PERIOD</h4>The transitional period must not be understood as a delay of application of the MDR. The following MDR provisions have to be complied with from May 26, 2021, in any scenario (Article 120 (3) MDR):<ul><li>Post-market surveillance (Article 83 et seq, “PMS”): as we have shown in <a target="_blank" href="https://lifesciences.mofo.com/topics/Software-as-a-Medical-Device-in-Europe--New-Regulatory-Regime-About-to-Enter-into-Force-Part-4-of-6.html">part 4 of this series</a>, manufacturers of MDSW need to establish a PMS system that systematically gathers records and analyzes relevant data on the quality performance of MDSW for its entire lifetime. As a result, the manufacturer needs to draw the necessary conclusions from the findings and implement preventive and corrective actions. Additionally, manufacturers of MDSW in Classes IIa to III have to prepare a Periodic Safety Update Report summarizing the results and conclusions out of the abovementioned aspects.</li></ul><ul><li>Vigilance (Article 87 et seq): Manufacturers of MDSW are required to investigate and report serious incidents and take and report field safety corrective actions with regard to their products. Furthermore, they have to report on trends concerning the frequency or severity of side effects that are documented in the MDSW informational material and the technical documentation. For further information on incident reporting, please refer to <a target="_blank" href="https://lifesciences.mofo.com/topics/Software-as-a-Medical-Device-in-Europe--New-Regulatory-Regime-About-to-Enter-into-Force-Part-4-of-6.html">part 4 of this series</a>.</li></ul><ul><li>Registration of economic operators and of devices (Article 29 et seq): manufacturers will have to register their MDSW in accordance with the Unique Device Identifier (“UDI”) system that we have covered extensively in <a target="_blank" href="https://lifesciences.mofo.com/topics/Software-as-medical-device-in-Europe--New-Regulatory-Regime-About-To-Enter-Into-Force--Part-5-of-6.html">Part 5 of our series</a>. In addition, they need to register themselves with a unique Single Registration Number (“SRN”) and, where applicable, the authorized representative and the importer. SRNs are assigned by the competent authorities in the EU member states. The registration will be carried out through the European Databank on Medical Devices (“EUDAMED”), which is in the process of being set up.</li></ul><ul><li>Market surveillance (Article 93): the provisions on market surveillance cover the duties and activities carried out by the competent authorities to ensure that medical devices do not pose significant risks to the health and safety of patients. It therefore does not directly apply to manufacturers of MDSW.</li></ul><h4>6. CONCLUDING REMARKS</h4>As it is to be expected that many Class I MDSW will be up-classified under the MDR, developers should be duly prepared to qualify for the transitional periods and put the delay to good use. First, they should assess any upcoming necessary changes to their products and plan on pushing back any of them that could be deemed significant, as they could lead to abrupt applicability of all relevant MDR requirements (although there may be cases where they are forced to implement changes under PMS). Second, manufacturers should familiarize themselves with their obligations regarding PMS, vigilance, and registration and be ready for full compliance from May 21, 2021. Third, they should start preparing for MDR certification as additional pressure on the Competent Authorities at the end of the transitional periods are predictable. Manufacturers should begin to, inter alia, collect clinical data on their MDSW, set up a Quality Management System, and draft Clinical Evaluation plans.Timely preparation is of the essence as only an on-time certification can ensure a smooth transition into the new (delayed) framework.[1] In the rare case that a device has an EC-verification as set out in Annex IV to the MDD, it can only be placed on the market until May 27, 2022 (Article 120 (2) MDR).

Wolfgang advises clients on contentious and non-contentious matters involving their most valuable intellectual property assets in the digital, high-tech, life sciences, and pharmaceutical industries.

kress_stephan_blog_150x150.png

kress_stephan_common_640x280.jpg

kress_stephan_heroretina_2700x1160.jpg

kress_stephan_mobileretina_750x1040.jpg

kress_stephan_social_600x600.jpg

Counsel

Stephan is counsel at Morrison Foerster’s German office in Berlin. He focuses on advising major German and international clients with regard to drafting and negotiating complex technology-related agreements and on matters concerning cloud computing, software, e/m-commerce, digital media, intellectual property rights, consumer rights, electronic communication, big data and cyber security requirements.

Stephan Kreß

Stephan is counsel at Morrison Foerster’s German office in Berlin. As a member of the technology transactions group, he focuses on advising major German and international clients with regard to drafting and negotiating complex technology-related agreements and on matters concerning cloud computing, software, e/m-commerce, digital media, intellectual property rights, consumer rights, electronic communication, big data and cyber security requirements.

grohmann_robert_blog_150x150.png

grohmann_robert_common_640x280.jpg

grohmann_robert_heroretina_2700x1160.jpg

grohmann_robert_mobileretina_750x1040.jpg

grohmann_robert_social_600x600.jpg

Robert advises companies from the technology and life sciences sectors on a wide range of commercial, intellectual property (IP) and regulatory matters. His clients range from multinational corporations to startups and scaleups.

Robert Grohmann

Robert Grohmann is counsel at Morrison Foerster’s German office in Berlin. As a member of the technology transactions group, he focuses on advising domestic and foreign companies and startups in all areas of technology and IP law, including patent and software licensing, employee inventions law, as well as know-how protection. Moreover, Mr. Grohmann’s expertise encompasses the judicial and extra-judicial representation in matters of trademark law, design law, and competition law.

mofolifesciences-eu.jpg

Software as a Medical Device in Europe – New Regulatory Regime About to Enter into Force – (Part 6 of 6)

Fourth Circuit’s Decision Revitalizes First Amendment Challenge to the TCPA

mofolifesciences-eu

In Part 6 of our series of consecutive articles on the reformed regulatory framework under the EU Medical Device Regulation 2017/745 (“MDR”), which will govern 

Software as a Medical Device in Europe – New Regulatory Regime About to Enter into Force – (Part 6 of 6)

On Friday, March 26, 2021, over 180 attendees worldwide attended McKinsey & Company’s first Global HealthTech CEO Connect of 2021. The discussion focused on regulatory and legal considerations for software as a medical device (SaMD) in both the United States and Europe and specific use cases for digital therapeutics and other digital health products. Speakers included Morrison & Foerster partners Bethany Hills and Wolfgang Schönig as well as special guest Corey McCann, president and CEO of Pear Therapeutics, in a fireside chat at the end of the program. Globally, the convergence of software technology and life sciences creates a massive opportunity for growth, and the market for these products is growing exponentially. Both the U.S. Food and Drug Administration (FDA) and European regulators have focused on establishing a regulatory framework for oversight of SaMD.After key definitions and concept overviews by the McKinsey team, Bethany Hills set the foundation of the FDA’s evolution in regard to SaMD in the United States and provided insights into the specific pathways impacting digital therapeutics. The FDA has not specifically defined SaMD, instead relying in the guidance documents on the definition provided by the International Medical Device Regulators Forum (IMDRF), which define the term as software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device. In essence, the software must act on its own, and have indications or be intended for the diagnosis, treatment, prevention, or monitoring of a condition. Medical devices in the United States are assigned one of three regulatory classes based on the risk and safety and effectiveness of the device. Most SaMD would fall under Class I or II, which then determines the type of submission required for authorization to market, including the 510(k) and De Novo pathways. Most devices are cleared under the 510(k) pathway; however, that trend is changing more recently, with many de novo submissions and authorizations involving SaMD. Areas to keep a close eye on include FDA’s finalization of its Clinical Decision Support Software Guidance, currently in draft form, and the Pre-Certification Pilot Program that could significantly impact SaMD if implemented outside the pilot program, by providing a faster, more efficient pathway to FDA authorization. The FDA does not make reimbursement-related decisions, however, a recent <a target="_blank" href="https://www.federalregister.gov/documents/2021/01/14/2021-00707/medicare-program-medicare-coverage-of-innovative-technology-mcit-and-definition-of-reasonable-and">CMS Final Rule</a> creates the Medicare Coverage of Innovative Technology (MCIT) pathway that will result in four years of national Medicare coverage starting on the date of the FDA’s market authorization of a device holding a Breakthrough Device Designation.  Providing the European perspective, Wolfgang took the stage to discuss the EU’s current regulatory landscape, and reimbursement for Digital Health Apps in Germany. The EU Medical Device Directive (MDD) will soon be replaced, effective May 26, 2021, by the EU Medical Device Regulation (MDR), directly applicable across the EU and significantly stricter for medical device software (MDSW) in three areas: prediction and prognosis applications, impact on the Class I categorization, and enhanced quality and safety requirements. After a review of the MDSW classifications and key changes to the Quality Management Systems, including more stringent requirements for Post-Market Surveillance activities, additional responsibilities along the supply chain, and stricter timeframes for document retention and incident reporting, the discussion turned to Unique Device Identification, which aims to enhance the effectiveness of post-market safety-related activities and traceability. Finally, the discussion focused on the application requirements for low risk apps (Class I or IIa) to receive reimbursement in Germany per the regulation on the Eligibility of Digital Health Applications for Reimbursement by the State Health Schemes (DiGAV), including certain interoperability requirements with the Electronic Patient File system, data protection requirements, and positive healthcare effects to be shown.Below are some highlights from the Q&A:1. Are there exceptions for software developed in a research setting/environment?a. In the United States, a software product can be used in a research and development setting without requiring the FDA’s authorization. However, there are nuances if the research setting involves human subjects.b. In the EU, the MDR generally applies to SaMD that is made available to others, including in a research setting. Yet, one important exception allows for the in-house development and use of SaMD in health institutions with only limited regulation (Article 5(5) MDR). The requirements to fulfill in order to benefit from this exception are rather strict. Most notably, they include that the specific needs for the targeted treatment cannot be met by any equivalent device on the market and that the SaMD is not transferred to another legal entity.2. Is there different regulatory treatment if the use of the medical device is for healthcare providers only vs. patients?a. In the United States, the answer depends on the category of the SaMD. For example,<a href="https://www.fda.gov/media/109618/download" target="_blank"> Clinical Decision Support</a> software has different standards applied for provider users v. patient users.b. The MDR in the EU does not expressly distinguish between groups of end-users; however, some regulatory requirements can make differentiated measures necessary. For example, instructions for use under certain circumstances may be delivered to professionals in electronic form while non-professional users can demand a printed version. Additionally, member states of the EU can decide that the instructions must be delivered in a certain language. In this regard, Germany requires documents to be in German for non-professional users but deems English instructions sufficient for professional users.3. What are some of the reimbursement options for SaMD companies?a. Reimbursement options and pathways seem elusive for SaMD companies, although there does seem to be an evolving path for the category of digital therapeutics.b. In the EU, reimbursement options for SaMD are not harmonized, i.e., each member state has established its own rules on the matter. This means, that the requirements to qualify for reimbursement differ significantly from country to country. Since the COVID-19 pandemic has seriously boosted the acceptance and demand for digital health products, some member states are currently revisiting their frameworks for reimbursement for SaMD. Germany, for instance, has enacted the DiGAV under which certain low risk apps (Class I or IIa) can receive reimbursement (see above and <a href="https://www.bfarm.de/SharedDocs/Downloads/EN/MedicalDevices/DiGA_Guide.pdf;jsessionid=04D2120BC0B889420CDDF02A652FA0D2.2_cid354?__blob=publicationFile&v=2" target="_blank">here</a>).4. What are the implications of GDPR on SaMD regulation in Europe? Among other issues to consider, the GDPR sets up restrictions for transfers of personal data from within the European Union to a country outside the EU. Please note that the meaning of “transfer” is understood quite broadly, and includes situations in which personal data becomes accessible to a third party, even if such third party does not actually access the data. Cross-border data transfers require a so-called transfer mechanism, which can usually be an adequacy decision by the European Commission for a particular country, EU model clauses, or binding corporate rules. Following the judgment of the European Court of Justice in the case “Schrems II,” in which the Court invalidated the EU-U.S. Privacy Shield, transfers to the United States have become particularly onerous to facilitate. Furthermore, EU member states may have introduced additional restrictions for transfers in the context of SaMD. For example, in Germany under the DiGAV, data transfers to the United States or any other non-EU country without an adequacy decision by the EU Commission is generally impossible. However, the German Federal Institute for Drugs and Medical Devices has issued guidance explaining under which circumstances it may be possible to use EU subsidiaries with parent companies in non-EU countries. More information is available <a href="https://www.bfarm.de/SharedDocs/Downloads/EN/MedicalDevices/Data_Processing_outside_of_Germany_FAQ.pdf?__blob=publicationFile&v=3" target="_blank">here</a>. Please note, however, that this topic is hotly debated and far from settled.5. How critical is HIPAA for companies in the U.S. market? HIPAA is a critical set of federal standards for privacy and security of protected health information. However, HIPAA is only one piece of the patchwork of privacy and security laws in the United States spanning federal and state requirements that could be applicable to SaMD.Related posts <a target="_blank" href="https://lifesciences.mofo.com/topics/Progress-and-Concerns-of-FDAs-Plan-for-Regulatory-Oversight-of-Artificial-IntelligenceMachine-Learning-AIML-Based-Software-as-Medical-Devices-SaMDs.html">FDA’s Plan for AI/ML-Based Software as Medical Devices: Progress and Concerns</a><a target="_blank" href="https://lifesciences.mofo.com/topics/FDA-Clinical-Decision-Support-Software-vs-EUs-Medical-Device-Regulation.html">FDA Clinical Decision Support Software Vs. EU’s Medical Device Regulation</a>  MoFo Life Sciences also features a six-part blog series discussing software as a medical device in Europe and the current regulatory landscape in more detail. Catch-up on parts 1-5 below and subscribe to our blog to receive the latest updates. <ul><li><a target="_blank" href="https://lifesciences.mofo.com/topics/Software-as-a-Medical-Device-in-Europe--New-Regulatory-Regime-About-to-Enter-into-Force--Part-1-of-6.html">New regulatory regime about to enter into force</a></li><li><a href="https://lifesciences.mofo.com/topics/Software-as-Medical-Device-in-Eu--New-Reg-Enter-into-Force--Part-2-of-6.html" target="_blank">A more detailed approach to the “intended purpose” </a> </li><li><a href="https://lifesciences.mofo.com/topics/Software-as-Medical-Device-in-Europe-New-Reg-Regime-to-Enter-into-Force-Part-3.html" target="_blank">Risk class re-categorization</a></li><li><a href="https://lifesciences.mofo.com/topics/Software-as-a-Medical-Device-in-Europe--New-Regulatory-Regime-About-to-Enter-into-Force-Part-4-of-6.html" target="_blank">Additional quality assurance and documentation requirements for MDSW</a></li><li><a href="https://lifesciences.mofo.com/topics/Software-as-medical-device-in-Europe--New-Regulatory-Regime-About-To-Enter-Into-Force--Part-5-of-6.html" target="_blank">Introduction of a Unique Device Identification requirement for MDSW</a></li></ul>

mofolifesciences-medical-devices.jpg

Global HealthTech CEO Connect: Software as a Medical Device in the U.S. and EU Recap

FDA Clinical Decision Support Software vs. EU’s Medical Device Regulation

mofolifesciences-medical-devices

On Friday, March 26, 2021, over 180 attendees worldwide attended McKinsey & Company’s first Global HealthTech CEO Connect of 2021. The discussion focused on reg

Global HealthTech CEO Connect: Software as a Medical Device in the U.S. and EU Recap

In follow-up to our colleagues recent <a target="_blank" href="https://lifesciences.mofo.com/topics/Software-as-Medical-Device-in-Europe-New-Reg-Regime-to-Enter-into-Force-Part-3.html">post</a> about the newly implemented Medical Device Regulation (“MDR”) in the European Union, this post will discuss some of the similarities between FDA’s Clinical Decision Support (“CDS”) Software Draft <a target="_blank" href="https://www.fda.gov/media/109618/download">Guidance</a> (together the “CDS Draft Guidance”) and the MDR. While still in draft form, we note that FDA has signaled its intent to finalize the CDS Draft Guidance in 2021.<h4>Statutory Framework</h4>Under the current CDS Draft Guidance, FDA first bases its approach to CDS on criteria set forth in the 21st Century Cures Act (the “Cures Act”). Excluded from the definition of a “device” under the Cures Act are software functions that met all four of the following criteria:(1) not intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern signal from a signal acquisition system;(2) intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines);(3) not intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition; and(4) intended for the purpose of enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.Notably, these criteria do not include software functions intended for a patient or caregiver; rather, these criteria apply only to those software functions for “health care professionals.” Accordingly, software device manufacturers must analyze all software functions utilized by patients and caregivers carefully using the CDS Draft Guidance to determine whether FDA will either exercise its oversight focus, requiring the software to receive FDA approval as a device, or its enforcement discretion.  <h4>IMDRF Framework</h4>FDA’s CDS Draft Guidance also relies on the International Medical Device Regulators Forum (“IMDRF”) Framework for Software as a Medical Device (“SaMD”) in approaching its interpretation of the criteria from the statue that would exclude a software from the definition of a medical device. The MDR also utilized this IMDRF framework for SaMD. IMDRF focuses on two factors, which are critical to the analysis of SaMD: (1) whether the user uses the information provided by a SaMD to treat or diagnose, to drive clinical management, or to inform clinical management; and (2) whether the patient’s healthcare situation or condition is critical, serious, or non-serious.The CDS Draft Guidance utilizes the IMDRF framework, and includes a variation of the classification used under Rule 11 by the European Commission’s <a href="https://ec.europa.eu/docsroom/documents/37581" target="_blank">Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745-MDR and Regulation (EU) 2017/746-IVDR</a>, to similarly categorize different types of SaMD.<table border="1" cellspacing="0" cellpadding="0"><tbody><tr><td width="156" rowspan="2" style="width: undefined%; height: auto;">State of healthcare situation or condition</td><td width="468" colspan="3" style="width: undefined%; height: auto;">Significance of information provided by SaMD tohealthcare decision</td></tr><tr><td width="156" style="width: undefined%; height: auto;">Treat ordiagnose</td><td width="156" style="width: undefined%; height: auto;">Drive clinical management</td><td width="156" style="width: undefined%; height: auto;">Inform clinicalmanagement</td></tr><tr><td width="156" valign="top" style="width: undefined%; height: auto;">Critical</td><td width="156" valign="top" style="width: undefined%; height: auto;">IV</td><td width="156" valign="top" style="width: undefined%; height: auto;">III</td><td width="156" valign="top" style="width: undefined%; height: auto;">II</td></tr><tr><td width="156" valign="top" style="width: undefined%; height: auto;">Serious</td><td width="156" valign="top" style="width: undefined%; height: auto;">III</td><td width="156" valign="top" style="width: undefined%; height: auto;">II</td><td width="156" valign="top" style="width: undefined%; height: auto;">I</td></tr><tr><td width="156" valign="top" style="width: undefined%; height: auto;">Non-serious</td><td width="156" valign="top" style="width: undefined%; height: auto;">II</td><td width="156" valign="top" style="width: undefined%; height: auto;">I</td><td width="156" valign="top" style="width: undefined%; height: auto;">I</td></tr></tbody></table> FDA uses the risk-categorizations described above to apply a risk-based policy to its regulation of Device CDS functions.<h4>Other Components of the CDS Draft Guidance</h4>In addition to the above framework from IMDRF, the CDS Draft Guidance also focuses on whether the intended user is a healthcare provider or a patient or caregiver and whether the user can independently review the basis for the recommendation from the software.  This focus on user-type and independent review, rooted in the Cures Act language, is a departure from the IMDRF (and the MDR’s) framework, which focuses more upon the intended use of the software and the medical conditions the software covers. As you can see in the table below, FDA has a demonstrated interest in those software functions where the intended user is a patient or caregiver, particularly when the device is informing clinical management for serious or critical healthcare situations or conditions. Similarly, when the intended user is a healthcare provider, FDA does not consider the software to be a device so long as the healthcare provider can independently review the basis for the recommendation.Combining the IMDRF Framework with FDA’s focus on the user-type and whether the user can independently review the basis for the recommendation, results in the following table:<table border="1" cellspacing="0" cellpadding="0"><tbody><tr><td width="249" colspan="2" valign="top" style="width: undefined%; height: auto;"> </td><td width="125" valign="top" style="width: undefined%; height: auto;">Intended User is HCP</td><td width="234" valign="top" style="width: undefined%; height: auto;">Intended User is Patient or Caregiver</td></tr><tr><td width="125" valign="top" style="width: undefined%; height: auto;">IMDRF Risk Categorization</td><td width="125" valign="top" style="width: undefined%; height: auto;">Can the User Independently Review the Basis?</td><td width="125" valign="top" style="width: undefined%; height: auto;">FDA Regulation</td><td width="234" valign="top" style="width: undefined%; height: auto;">FDA Regulation</td></tr><tr><td width="125" rowspan="2" valign="top" style="width: undefined%; height: auto;">InformxCritical</td><td width="125" style="width: undefined%; height: auto;">Yes</td><td width="125" style="width: undefined%; height: auto;">Not a Device</td><td width="234" style="width: undefined%; height: auto;">Oversight Focus</td></tr><tr><td width="125" style="width: undefined%; height: auto;">No</td><td width="125" style="width: undefined%; height: auto;">Oversight Focus</td><td width="234" style="width: undefined%; height: auto;">Oversight Focus</td></tr><tr><td width="125" rowspan="2" valign="top" style="width: undefined%; height: auto;">InformxSerious</td><td width="125" style="width: undefined%; height: auto;">Yes</td><td width="125" style="width: undefined%; height: auto;">Not a Device</td><td width="234" style="width: undefined%; height: auto;">Oversight Focus</td></tr><tr><td width="125" style="width: undefined%; height: auto;">No</td><td width="125" style="width: undefined%; height: auto;">Oversight Focus</td><td width="234" style="width: undefined%; height: auto;">Oversight Focus</td></tr><tr><td width="125" rowspan="2" valign="top" style="width: undefined%; height: auto;">InformxNon-Serious</td><td width="125" style="width: undefined%; height: auto;">Yes</td><td width="125" style="width: undefined%; height: auto;">Not a Device</td><td width="234" style="width: undefined%; height: auto;">Enforcement Discretion</td></tr><tr><td width="125" style="width: undefined%; height: auto;">No</td><td width="125" style="width: undefined%; height: auto;">Enforcement Discretion</td><td width="234" style="width: undefined%; height: auto;">Oversight Focus</td></tr></tbody></table> <h4>Examples</h4>The CDS Draft Guidance provides a number of examples where FDA works through its framework. These examples walk through the IMDRF framework while considering the intended user and whether the user can independently review the recommendation from the SaMD.Non-Device CDSFDA considers the following software to not be a device: software that compares patient signs, symptoms, or results with available practice guidelines (institutions-based or academic/clinical society-based) to recommend condition-specific diagnostic tests, investigations, or therapy to healthcare providers. In this example, the software uses practice guidelines as the basis for the recommendation and provides such guidelines to the healthcare provider to review, such that the health care provider does not rely primarily on the software’s recommendation.Enforcement DiscretionFDA plans to utilize its enforcement discretion on software that assist a patient in identifying an over-the-counter cold or allergy medication to consider purchasing based on symptoms. In this example, the software would include appropriate warnings about products with overlapping ingredients. This software is device CDS because it is intended for a patient; however, FDA does not intend to enforce compliance because the software is intended to provide options to patients for the treatment of a non-serious situation or condition and because the patient can independently review the basis for the software’s recommendations.Oversight FocusFDA plans to focus its regulatory oversight on device CDS functions intended for patients, where the software is informing clinical management of serious or critical conditions. For example, FDA intends to regulate the following as device CDS: a software function that recommends when the parent or caregiver of pediatric patients with cystic fibrosis should take a child to the emergency room by aggregating information based on patient-specific symptoms and care guidelines. This software is device CDS because a caregiver uses the software and the software informs clinical management for a critical situation or condition, particularly because of the fragility of the target population.   <h4>Conclusion</h4>Recognizing that companies with global offerings face a complexity of issues, companies should seek to leverage similarities amongst the regulatory classification of SaMD and CDS. However, companies should simultaneously be acutely attuned to the critical differences in how those frameworks are applied by the applicable regulatory bodies. There is a need for attention to these issues, particularly with the upcoming finalization of the CDS guidance in FY2021 by FDA and the MDR coming into effect on May 26, 2021.

FDA Clinical Decision Support Software vs. EU’s Medical Device Regulation

In follow-up to our colleagues recent post about the newly implemented Medical Device Regulation (“MDR”) in the European Union, this post will discuss some of t

The preceding articles of this <a target="_blank" href="https://lifesciences.mofo.com/topics/Software-as-a-Medical-Device-in-Europe--New-Regulatory-Regime-About-to-Enter-into-Force--Part-1-of-6.html">series </a>laid out how the new EU Medical Device Regulation 2017/745 (“MDR”) leads to a broader coverage of medical devices and an overall deeper level of regulation in areas already regulated before.  This episode will put the spotlight on a feature introduced to the European market of medical devices for the first time: the Unique Device Identification (“UDI”) system, also referred to as the bar-code system for medical devices.<h4>INTRODUCTION</h4>Following the lifecycle approach of the MDR, the identification system aims to enhance the effectiveness of the post-market safety-related activities. The system brings about two key obligations: device labeling and data submission requirements.  If this does not sound at all novel, it might be for other medical device markets, such as the U.S., that have had similar rules in place for quite some time.  The UDI is obtained through officially designated entities, some of which are entrusted by both EU and U.S. authorities.  The data submissions will have to be made to the European Databank on Medical Devices (“<a href="https://eudamed.eu/" target="_blank">EUDAMED</a>”), which is in the process of being set up. Submissions of UDI data to EUDAMED will be mandatory beginning November 26, 2022. However, providers of medical device software (“MDSW”) can start the process of obtaining a UDI immediately.<h4>1. UDI FORMATS</h4>The MDR requires a medical device to be labelled with a certain UDI, which allows for a clear and unambiguous identification of specific medical devices and facilitates their traceability on the market. What is visible, is called the “UDI-carrier,” which can either be an automatic identification and data capture (“AIDC”) (i.e., bar codes, smart cards, biometrics, etc.) or a human-readable interpretation (“HRI”) (a series of numeric or alphanumeric characters). All of the issuing entities, currently <a href="https://ec.europa.eu/docsroom/documents/38582?locale=en" target="_blank">GS1</a>, <a href="https://ec.europa.eu/docsroom/documents/38564?locale=en" target="_blank">HIBCC</a>, <a href="https://ec.europa.eu/docsroom/documents/38566?locale=en" target="_blank">ICCBBA</a>, and <a href="https://ec.europa.eu/docsroom/documents/38581?locale=en" target="_blank">IFA GmbH</a>, have their own algorithm to create UDIs. The format is based on guidelines (<a href="https://ec.europa.eu/health/sites/health/files/md_sector/docs/md_mdcg_2019_1_budi_rules_ie_en.pdf" target="_blank">here</a>) but will be specific to the issuing entity.  An example of a human-readable UDI assigned by IFA GmbH could be “(9N)1101234568(S)ABC123.”According to Article 27 of the MDR, the UDI comprises of a Device Identifier (“UDI-DI”), which is specific to a manufacturer and a device, and the Production Identifier (“UDI-PI”), which identifies the unit of device production.The UDI-DI is linked to a so-called Basic UDI-DI that connects devices with the same intended purpose, risk class, and essential design and manufacturing characteristics, identifying a certain group of devices. The Basic UDI-DI itself will not be placed on the product but has to be provided to EUDAMED.<h4>2. UDI FOR MDSW</h4>Annex VI Part C Point 6.5 of the MDR addresses the UDI assignment on MDSW specifically. Some guidance on the <a href="https://ec.europa.eu/health/sites/health/files/md_sector/docs/md_mdcg_2018_5_software_en.pdf" target="_blank">UDI assignment to MDSW</a> provided by the Medical Device Coordination Group is provided <a href="https://ec.europa.eu/health/sites/health/files/md_sector/docs/md_mdcg_2018_5_software_en.pdf" target="_blank">here</a>, according to which UDI-DI shall be assigned to stand-alone MDSW (available on its own and software that constitutes a device in itself) at the system level of such MDSW. If MDSW is sold on a physical medium, every level of packaging needs to display UDI in AIDC format and HRI format. Software comprising a user interface must display the UDI easily accessible in plain-text format, while software without a user interface needs to be able to transfer the UDI by API.Upon substantial changes to the MDSW, a new UDI-DI is required (Annex VI Part C Point 6.5.2 of the MDR). Guidance on changes can be found <a href="https://ec.europa.eu/docsroom/documents/40322" target="_blank">here</a>. Such new UDI-DI requirements are also triggered upon a change to Basic UDI-DI that impacts the original performance, safety, or the interpretation of data or to the name or trade name, version or model number, critical warnings or contraindications, or user interface language. Minor software revisions, such as bug fixes, usability enhancements that are not for safety purposes, security patches, or operating efficiency, shall require a new UDI-PI and not a new UDI‑DI.<h4>3. CONCLUDING REMARKS</h4>With the introduction of the UDI system, the MDR steps up the post-market transparency and levels with what seems to have become an international regulatory standard. For providers of MDSW, this means to plan for additional steps before placing their products on the market. From a regulatory perspective, it is necessary to obtain a UDI and provide data to EUDAMED, while practically a labeling concept has to be developed.Against this background, manufacturers of medical devices should bear in mind the timeline regarding the obligation of UDI assignment, which depends on the device class. High-risk devices in Class III start on May 26, 2021, followed by Class IIa and IIb devices, which are due on May 26, 2023. The low-risk devices in Class I are due on May 26, 2025. Links to previous articles in the series: <a target="_blank" href="https://lifesciences.mofo.com/topics/Software-as-a-Medical-Device-in-Europe--New-Regulatory-Regime-About-to-Enter-into-Force--Part-1-of-6.html">SOFTWARE AS A MEDICAL DEVICE IN EUROPE – NEW REGULATORY REGIME ABOUT TO ENTER INTO FORCE – (PART 1 OF 6)</a><a target="_blank" href="https://lifesciences.mofo.com/topics/Software-as-Medical-Device-in-Eu--New-Reg-Enter-into-Force--Part-2-of-6.html">SOFTWARE AS A MEDICAL DEVICE IN EUROPE – NEW REGULATORY REGIME ABOUT TO ENTER INTO FORCE – (PART 2 OF 6)</a><a target="_blank" href="https://lifesciences.mofo.com/topics/Software-as-Medical-Device-in-Europe-New-Reg-Regime-to-Enter-into-Force-Part-3.html">SOFTWARE AS A MEDICAL DEVICE IN EUROPE – NEW REGULATORY REGIME ABOUT TO ENTER INTO FORCE – (PART 3 OF 6)</a><a target="_blank" href="https://lifesciences.mofo.com/topics/Software-as-a-Medical-Device-in-Europe--New-Regulatory-Regime-About-to-Enter-into-Force-Part-4-of-6.html">SOFTWARE AS A MEDICAL DEVICE IN EUROPE – NEW REGULATORY REGIME ABOUT TO ENTER INTO FORCE – (PART 4 OF 6)</a>

Software As A Medical Device In Europe – New Regulatory Regime About To Enter Into Force – (Part 5 of 6)

The preceding articles of this series laid out how the new EU Medical Device Regulation 2017/745 (“MDR”) leads to a broader coverage of medical devices and an o

Software As A Medical Device In Europe – New Regulatory Regime About To Enter Into Force – (Part 5 of 6)

After having dealt with the issue when software may be considered a medical device according to its intended purpose (in <a target="_blank" href="https://lifesciences.mofo.com/topics/Software-as-Medical-Device-in-Eu--New-Reg-Enter-into-Force--Part-2-of-6.html">part 2</a>) and the implications of the new risk classification regime (in <a href="https://lifesciences.mofo.com/topics/Software-as-Medical-Device-in-Europe-New-Reg-Regime-to-Enter-into-Force-Part-3.html" target="_blank">part 3</a>), in this part 4 of our <a href="https://lifesciences.mofo.com/topics/Software-as-a-Medical-Device-in-Europe--New-Regulatory-Regime-About-to-Enter-into-Force--Part-1-of-6.html" target="_blank">series on Software as a Medical Device in Europe</a>, we will now explore key changes to the quality assurance and documentation requirements for stand-alone medical device software (“MDSW”) under the new <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32017R0745&from=EN" target="_blank">EU Medical Device Regulation 2017/745</a> (“MDR”).<h4>INTRODUCTION: A NEW LIFE CYCLE-FOCUSED APPROACH</h4>While the current <a target="_blank" href="https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CONSLEG:1993L0042:20071011:en:PDF">EU Medical Device Directive 93/42/EEC</a> (as amended by Directive 2007/47/EC – “MDD”) primarily focusses on the pre-approval stage of a medical device and how the manufacturer can obtain the CE marking, the MDR deploys a product life cycle-focused approach, aiming to establish responsibilities of medical device companies throughout the life cycle of the product. While not all requirements are new, to ensure conformity of the MDSW with the MDR, detailed and partly enhanced requirements concerning quality management, risk management, clinical evaluation, and technical documentation must be complied with post-market for the time the MDSW is in service.<h4>1. QUALITIY MANAGEMENTS SYSTEMS</h4>Article 10(9) of the MDR has extended the scope of the Quality Management Systems (“QMS”) required to be in place for MDSW. Key changes include:<ul><li>Document Control. More so than the MDD, the MDR requires continuous alignment and updating of the documentation with regard to available data, records, and post-market surveillance (see, e.g., Article 83(3) and Annex IX, I 2.2 (c) MDR). This will require the manufacturer to maintain a seamless system of data and information, ensuring that documents are generated and updated in a coordinated and coherent way throughout the organization.</li></ul><ul><li>Post-Market Surveillance: According to Articles 83 and 84 of the MDR, for each device, the manufacturer shall implement, maintain, document, and update a post-market surveillance system that shall be suited to actively and systematically gather, record, and analyze relevant data on the quality, performance, and safety of a device throughout its entire lifetime, and to draw the necessary conclusions and take preventive and corrective actions. This includes continuously updating the risk assessment and technical files of the MDSW. The post-market surveillance system shall be based on a post-market surveillance plan, the requirements for which are set out in Section 1.1 of Annex III.</li></ul><ul><li>Periodic Safety Update Report. Manufacturers of class IIa, class IIb, and class III devices have to prepare a Periodic Safety Update Report (“PSUR”) for each device (or category or group of devices, as applicable), summarizing the results and conclusions based on the post-market surveillance data and any preventive and corrective actions taken (Article 86 of the MDR). For class IIb and class III devices, the PSUR shall be updated at least annually.</li></ul><ul><li>General Safety and Performance Requirements. The “essential requirements” under the MDD have been replaced by the “General Safety and Performance Requirements” (GSPR). GSPR for software are included in the new Section 17.2 of Annex I. According to this provision, software shall be developed and manufactured in accordance with the state of the art, taking into account the principles of development life cycle and risk management, including information security, verification, and validation. According to Article 8 of the MDR, compliance with so-called harmonized standards creates the presumption of conformity with the GSPR of Annex I. While there are over 250 harmonized standards for the MDD, there are currently no relevant harmonized standards for the MDR. Manufacturers will need to adhere to existing relevant standards (e.g., IEC 62304:2006 – Medical device software – Software life-cycle processes) but should pay close attention to any upcoming harmonized standards.</li></ul><ul><li>Supply Chain. Under the MDR, required scrutiny with regard to suppliers and outsourced processes is increased. The documentation requirements pertaining to the supply chain are stipulated in Article 25 of the MDR. While manufacturers already have responsibilities for stand-alone MDSW under the MDD, the MDR sets out specific new requirements for other economic operators like authorized representatives (Article 11 and 12), importers (Article 13), distributors (Article 14), and sterilizers and packaging (Article 22) in this regard. Manufactures have to ensure that everyone in the supply chain of its MDSW who is considered an “economic operator” under the MDR understands the key changes to quality management and has a plan in place for compliance with their specific responsibility under the MDR.</li></ul><ul><li>Document Retention. The period during which manufacturers have to store technical documentation has extended from five to 10 years after the last device has been placed on the market (Annex IX Section 7 MDR). For implants it is, and has been, 15 years.</li></ul><ul><li>Incident Reporting. The deadline for reporting serious incidents involving medical devices made available on the EU market to the competent authorities has been shortened from 30 days (for incidents not amounting to serious public health threats, death, or serious deterioration in health) under the MDD (MEDDEV 2 12-1, Section 5.1.7) to 15 days under the MDR (Article 87(3) MDR).</li></ul>Manufacturers of MDSW find a framework for QMS in <a href="https://www.iso.org/standard/59752.html" target="_blank">ISO 13485</a>, which provides a safe and easy way to prove conformity. While certification under this already-established standard will be the main path to establish QMS compliance under the MDR, manufacturers of MDSW with an existing QMS must ensure that the new and amended requirements under the MDR are covered by their existing QMS. Manufacturers should note that all QMS requirements must be met as of May 26, 2021, even if certain medical devices offered by them fall under a transition period.<h4>2. CLINICAL EVALUATIONS</h4>All manufacturers of medical devices are obligated to conduct a clinical evaluation. The MDR provides for requirements that are more precise as compared to the MDD regime, particularly regarding the post-market obligations. Clinical evaluation means a systematic and planned process to continuously generate, collect, analyze, and assess the clinical data pertaining to a device in order to verify the safety and performance, including clinical benefits, of the device when used as intended by the manufacturer. A sufficient amount and quality of clinical data have to underpin scientific validity, technical, and clinical performance. The Post-Market Clinical Follow-up (“PMCF”) that already existed under the MDD is now specified in more detail in Annex XIV Part B. A newly introduced requirement is the PMCF evaluation report, which shall provide analyzed findings of the PMCF. A template for the PMCF evaluation report can be found <a href="https://ec.europa.eu/docsroom/documents/40906" target="_blank">here</a>. The Medical Device Coordination Group provides guidance on relevant aspects regarding MDSW, focused on international standards (<a href="https://ec.europa.eu/health/sites/health/files/md_sector/docs/md_mdcg_2020_1_guidance_clinic_eva_md_software_en.pdf" target="_blank">MDCG 2020-1</a>). The MDCG 2020-1 identifies three key components that need to be taken into account when compiling clinical evidence for every MDSW:<ul><li>Scientific Validity (Valid Clinical Association). There needs to be a valid scientific association between the output of the MDSW (calculations, recommendations, etc.) based on the input and algorithms selected on the one hand and the targeted physiological state or clinical condition on the other hand. For example, if the MDSW is designed to detect a certain disease by analyzing abnormal measurement values, there needs to be a valid clinical association between the analyzed measurement values and the disease in question. The association must be well founded or clinically accepted. This component seeks to establish that the use of the MDSW is based on sound scientific principles.</li></ul><ul><li>Technical Performance (Analytical Performance). The MDSW must be able to accurately, reliably, and precisely generate the intended output from the input data. Evidence of this can be generated through verification and validation activities.</li></ul><ul><li>Clinical Performance. For those features of the MDSW that claim a specific clinical benefit, the manufacturer must demonstrate that the MDSW can achieve clinically relevant output in accordance with the intended purpose. For the validation of an MDSW’s clinical performance, the MDSW must have been tested (i) for the intended use(s) on the target population(s), (ii) under the use condition(s) and operating and use environment(s), and (iii) with all intended user group(s).</li></ul><h4>3. TECHNICAL DOCUMENTATION</h4>Requirements for the technical documentation of the MDSW are now explicitly addressed in Article 10(4) and Annexes II and III of the MDR. With regard to the technical documentation, the MDR brings about increased requirements, along with more details on how technical documentation has to be carried out and structured. The technical documentation has to be drawn up in a “clear, organized, readily searchable and unambiguous manner.” Annexes II and III of the regulation list elements to be contained, which in the pre-market phase include (i) information on device description and specification, including variants and accessories; (ii) information to be supplied by the manufacturer; (iii) design and manufacturing information; (iv) general safety and performance requirements; (v) risk-benefit analysis and risk management; and (vi) product verification and validation. As outlined above, any MDSW that is available on the market must be covered by a post-market surveillance plan according to Article 84, a post-market surveillance report according to Article 85, and a periodic safety update report according to Article 86 (PSUR) if class IIa or higher. The newly introduced PMCF evaluation report shall form part of the PSUR.<h4>CONCLUDING REMARKS</h4>The new life cycle-oriented approach under the MDR requires manufacturers of stand-alone MDSW to reassess their current quality management and documentation strategy and to set up a comprehensive process that encompasses, among other things, QMS and technical documentation post-market surveillance procedures. As it might take months to have a complying QMS in place, suppliers of MDSW need to be working on this now if they have not already done so.

Software as a Medical Device in Europe – New Regulatory Regime About to Enter into Force – (Part 4 of 6)

After having dealt with the issue when software may be considered a medical device according to its intended purpose (in part 2) and the implications of the new

Software as a Medical Device in Europe – New Regulatory Regime About to Enter into Force – (Part 4 of 6)

U.S. Food and Drug Administration (FDA) has acknowledged the prevalence of Artificial Intelligence/Machine Learning (AI/ML)-Based Software as Medical Devices (SaMDs) and has been taking steps towards advancing its regulatory oversight. The FDA recently published an AI/ML SaMD action plan, developed in direct response to stakeholder feedback. It is now one month later, and the FDA has yet to implement any steps outlined in its action plan, all the while approving more and more AI products. This post discusses the progress the FDA has made thus far for regulating AI/ML-based SaMDs and the concerns that remain.<h4>FDA’s Progress for Regulatory Oversight</h4>Artificial intelligence is growing rapidly in the field of healthcare. The <a target="_blank" href="https://www.fda.gov/medical-devices/software-medical-device-samd/artificial-intelligence-and-machine-learning-software-medical-device">FDA has acknowledged</a> its importance and the impact it has on health care, but has not been able to keep up with manufacturers. In April 2019, the FDA published “<a target="_blank" href="https://www.fda.gov/files/medical%20devices/published/US-FDA-Artificial-Intelligence-and-Machine-Learning-Discussion-Paper.pdf">Proposed Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD) – Discussion Paper and Request for Feedback</a>,” describing for the first time, clearly, the FDA’s potential approach to premarket review of AI/ML SaMDs. The potential approach involved a “Predetermined Change Control Plan” for premarket submissions including “SaMD Pre‑Specifications” (SPS) and an “Algorithm Change Protocol” (ACP) to account for the iterative nature of AI/ML-based SaMDs.In February 2020, the FDA announced a marketing authorization via the De Novo pathway for the <a target="_blank" href="https://www.fda.gov/news-events/press-announcements/fda-authorizes-marketing-first-cardiac-ultrasound-software-uses-artificial-intelligence-guide-user">first cardiac ultrasonic software that uses AI to guide users</a>. The manufacturer used a Predetermined Change Control Plan in its application to obtain authorization.In the same month, the FDA held a public workshop on the “Evolving Role of Artificial Intelligence in Radiological Imaging.” The FDA and the public stakeholders discussed best practices for validation of AI‑automated radiological imaging software and image acquisition devices.In September 2020, FDA launched the <a target="_blank" href="https://www.fda.gov/news-events/press-announcements/fda-launches-digital-health-center-excellence">Digital Health Center of Excellence</a> within the Center for Devices and Radiological Health. According to the FDA, the focus of the Digital Health Center of Excellence is “helping both internal and external stakeholders achieve their goals of getting high quality digital health technologies to patients by providing technological advice, coordinating and supporting work being done across the FDA, advancing best practices, and reimaging digital health device oversight.”In January 2021, the FDA published “<a target="_blank" href="https://www.fda.gov/news-events/press-announcements/fda-releases-artificial-intelligencemachine-learning-action-plan">Artificial Intelligence/Machine Learning (AI/ML)‑Based Software as a Medical Device (SaMD) Action Plan</a>,” outlining the FDA’s plans for progressing its regulatory oversight. The Action Plan identified five areas for the FDA focus: <ol><li>Tailored regulatory framework for AI/ML-based SaMDs; </li><li>Good machine learning practices (GMLPs); </li><li>Patient-centered approach incorporating transparency to users; </li><li>Regulatory science methods related to algorithm bias and robustness; and </li><li>Real-world performance (RWP).  </li></ol>The FDA stated that it will update its regulatory framework and publish a draft guidance in 2021, actively engage in efforts to harmonize GMLPs, hold public workshops on device labeling for transparency to users, develop methodology for evaluating and improving machine learning algorithms (including identifying and eliminating bias), and develop a framework for gathering and validating RWP. Although the AI/ML Action Plan is recent, the FDA has not yet taken any steps to implement any of these focus areas for policy development or clarification.<h4>The FDA’s Approval of AI/ML-Based SaMDs</h4>Since 2012, the FDA has approved over 160 medical AI/ML-based SaMDs, the majority being in 2019 and 2020. Some <a target="_blank" href="https://www.statnews.com/2021/02/03/fda-artificial-intelligence-clearance-products/">reports</a> have found, upon investigation, that the requirements the FDA has imposed on device submission have been inconsistent. For example, some submission sponsors disclosed the amount of patient data used to validate the performance of their devices while others did not. And, according to one investigative <a target="_blank" href="https://www.statnews.com/2021/02/03/fda-clearances-artificial-intelligence-data/">report</a>, when disclosed, the amount of data varied widely from 100 patients on one end of the spectrum to 15,000 patients on the other end. Only a handful of manufacturers reported racial makeup of the study populations and a few provided gender breakdown. This creates uncertainty as to how effective the AI/ML-based SaMDs will perform with respect to algorithmic bias. Additionally, the FDA has not made training and testing data for these approved AI/ML-based SaMDs publicly available, potentially creating a lack of trust in these technologies or, at the very least, making it difficult for purchasers of the SaMDs to make informed decisions based on similar evidence criteria. However, perhaps most importantly, the FDA has yet to figure out how to handle real-world leaning and adaptation within the regulatory framework. Although the FDA clearly aims for increased regulation and monitoring of AI/ML-based SaMDs, it has not provided a specific plan for any of the five focus areas identified in its AI/ML Action Plan. The FDA may need to act much quicker in developing consistent standards as the number of AI/ML-based SaMDs submissions to the FDA continue to increase (from two products in 2012 to 70 products in 2019). The FDA should address stakeholder concerns of data and approval process inconsistencies, lack of well-established standards, transparency, labeling challenges, trustworthiness, algorithmic biases, and RWP. ConclusionThe FDA is slowly taking steps towards its commitment to develop a regulatory framework for AI/ML-based SaMDs. For now, the FDA has not yet provided any consistent standards. Without such widely-applicable guidance, manufacturers should expect a longer application timeline and extensive discussions with the FDA—in effect creating a customized plan for data and evidence generation for each and every AI/ML SaMD. It is unpredictable at this stage what the FDA will require and ask for in these negotiations, although to some extent prior submissions and authorizations serve as a baseline for consideration. As artificial intelligence and machine learning technologies are increasing in availability and applicability, organizations and device sponsors will continue to build their own databases and define their own standards, which the FDA may be strategically waiting for.

Round Rock Research, LLC v. [Multiple Defendants]

Sage Electrochromics, Inc. v. View, Inc.&nbsp;

nguyen_jean_blog_150x150.png

nguyen_jean_common_640x280.jpg

nguyen_jean_heroretina_2700x1160.jpg

nguyen_jean_mobileretina_750x1040.jpg

nguyen_jean_social_600x600.jpg

Of Counsel

A former lead engineer at the NASA Jet Propulsion Laboratory, Dr. Nguyen focuses her practice on domestic and international patent prosecution. She is a founder and co-leader of the firm’s Life Scienc