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

Patent-Eligibility Considerations & Prosecution Strategies for AI-Based Life Sciences Patent Applications

AI Transparency in Healthcare: Navigating a Changing Regulatory Landscape

Recentive: Raising the Patent-Eligibility Bar in AI-Related Inventions

April 2025 Update on Regulation of New Genomic Techniques in the EU

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

LinkedIN

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.

mofolifesciences-medical-devices.jpg

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

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

mofolifesciences-medical-devices

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>

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 5 of 6)

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

mofolifesciences-eu

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)

Having shed light on the relevance of the intended purpose of a medical device when determining whether software qualifies as medical devices software (“MDSW”) under the new EU Medical Device Regulation 2017/745 (“MDR”) in <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">part 2</a> 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 of articles</a>, in this part 3, we now turn to the issue of risk classification of such MDSW under the MDR.<h4>INTRODUCTION</h4>Under 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”), most stand-alone MDSW (i.e., MDSW not implemented in a more complex medical device, such as control software) including, for instance, a mobile app that allows users to take pictures of moles on their skin and evaluates whether it is a melanoma, are classified as Class I medical devices and therefore subject to self-certification (see <a href="https://ec.europa.eu/health/sites/health/files/md_topics-interest/docs/md_borderline_manual_05_2019_en.pdf" target="_blank">Manual on Borderline and Classification, Version 1.22</a>, page 81). This is likely going to change under the MDR, coming into full effect on May 26, 2021. Due to new classification rules, significantly more stand-alone MDSW will likely be classified as Class IIa or higher. This means that obtaining CE markings for stand-alone MDSW will more often require involvement of a notified body with an increasing level of scrutiny depending on the determined class.<h4>1. THE EU RISK CLASSIFICATION SYSTEM</h4>Already under the current MDD regime, medical devices, such as stand-alone MDSW, are classified according to their intended purpose and their inherent risks, and are divided into the following four risk classes: Class I (lowest-risk class), Class IIa, Class IIb, and Class III (highest‑risk class).These risk classes determine which conformity assessment procedures are required to obtain CE markings and range from self-certification (for Class I) to a full review of the technical design and manufacture of the specific device by a notified body (for Class III). Self-certification includes compliance with general safety and performance requirements, performance of clinical evaluation, preparation of technical documentation, and the issuance of an EU Declaration of Conformity. In addition to that, a Class IIa examination requires that a notified body examines the quality management system (“QMS”) and the technical data of one representative product sample per product category. In Class IIb, examination is conducted per generic product group, and in Class III, the QMS and technical data of every product must be examined.<h4>2. AMENDED RISK CLASSIFICATION SYSTEM FOR MDSW UNDER THE MDR </h4>The classification of MDSW under the MDR will take place in accordance with Annex VIII of the MDR. For classification purposes, MDSW, just like hardware devices, is considered an active device and can be classified in all four risk classes. Depending on whether the MDSW is a stand‑alone MDSW, an accessory to a hardware device, or drives or influences the use of a hardware device for a medical purpose, Rules 9, 10, 11, 12, 13, 15, and 22 of Annex VIII, Chapter 3 to the MDR (the “Rules”), can be relevant. Stand-alone MDSW, such as most health apps, will be classified independently from any hardware medical device (Annex VIII, Chapter 2, para. 3.3 of the MDR) and will thus mainly be governed by Rule 11 of Annex VIII to the MDR (“Rule 11”).According to Rule 11:(a)   Software intended to provide information that is used to take decisions with diagnosis or therapeutic purposes is classified as Class IIa, except if such decisions have an impact that may cause:<ul><li>Death or an irreversible deterioration of a person’s state of health, in which case it is Class III; or </li><li>A serious deterioration of a person’s state of health or a surgical intervention, in which case it is classified as Class IIb. </li></ul>(b)   Software intended to monitor physiological processes is classified as Class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as Class IIb.(c)   All other software is classified as Class I.In light of the foregoing it seems that a significant portion of stand-alone MDSW will fall in the higher risk classes IIa to III, as most of the stand-alone MDSW with an intended medical purpose will likely also provide information that is used for decision-making with diagnosis or therapeutic purposes.<h4>3. A MORE DIFFERENCIATED APPROACH TO CLASSIFICATION</h4>However, classification of stand-alone MDSW under the MDR will not be black and white. Guidance and a more detailed approach on risk categorizations and classification under Rule 11 is provided 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> (in the version of October 2019; “MDCG 2019-11”). Although the MDCG 2019-11 are not binding, as official documents, they should be taken into consideration when assessing software for classification under the MDR.According to the MDCG 2019-11, Rule 11 mirrors the regulatory guidance developed at the international level — more specifically, in the context of the International Medical Device Regulators Forum (“IMDRF”). The IMDRF framework for risk categorization of software as a medical device (SaMD) (“IMDRF Risk Framework”) categorizes the risk of software based on the combination of two factors:        i.            the significance of the information provided by the software to the healthcare decision,and      ii.            the healthcare situation or patient condition.In this regard, the IMDRF has developed a table for assisting manufacturers in identifying the appropriate risk category for their MDSW. This table was further supplemented by the European Commission and included in Annex III to the MCDG (“Amended IMRF Framework”) to reflect the corresponding MDR risk classes according to Rule 11:<div class="embedded-entry redactor-component block-entry" type="entry" data-sys-entry-uid="blt884195cd18c433c7" data-sys-entry-locale="en-us" data-sys-content-type-uid="image_content" sys-style-type="block"><div data-reactroot=""><img src="https://media2.mofo.com/v3/images/blt5775cc69c999c255/blt8bcd954f749ec7e1/62731787b5ad5f2863c59610/annexiii2.png?format=auto&amp;quality=60" alt="Annex III Table"></div></div>Source: Annex III of the MDCG 2019-11The Amended IMRF Framework allows a more differentiated approach to risk categorization and classification of stand-alone MDSW under Rule 11. For example, a mobile app intended to analyze a user’s heartbeat, detect abnormalities, and inform a physician accordingly may be classified as Class IIb per Rule 11(a), if the information provided by the software is intended to guide the physician in the diagnosis, because the information drives clinical management and the health care situation can be critical.[1] Yet, if the MDSW were intended to automatically adapt treatment (e.g., medication plans) of, for example, cardiac arrhythmias, it may be classified as Class III per Rule 11(a), as not only would the health care situation be critical but the MDSW would also be used to take immediate action to treat a disease or a condition.On the other hand, MDSW intended to rank therapeutic suggestions for a health care professional based on patient history, imaging test results, and patient characteristics (e.g., a MDSW that lists and ranks all available chemotherapy options for BRCA-positive individuals) may be classified as class IIa per Rule 11(a) since, albeit cancer being a critical disease, the MDSW only informs clinical management about the options.[2]It must be noted that the table does not take into account MDSW, which is Class I, as Class I MDSW falls outside the IMDRF risk categories.<h4>4. ROOM FOR CLASS I CLASSIFICATION OF MDSW</h4>However, a classification in Class I still remains possible. This will be the case for stand-alone MDSW that — even though intended for medical purposes — stays under the threshold set out by Rules 11(a) and (b) and thus falls under Rule 11(c). Manufacturers of MDSW should therefore not assume by default that any MDSW must at least be Class IIa but will still find it worthwhile to carefully assess whether the features of the software do not rather warrant a Class I categorization.For example, an app intended to support conception by calculating the user’s fertility status based on a validated statistical algorithm in which the user inputs her own health data (i.e., basal body temperature (BBT) and menstruation days) to track and predict ovulation and in which the fertility status of the current day is reflected by one of three indicator lights (i.e., red = fertile, green = infertile, or yellow = cycle fluctuation) may be regarded as Class I, as this MDSW is neither used to take decisions with diagnosis or therapeutic purposes, nor does it monitor physiological processes. Another example may be a mobile app that assists users with a medical condition to self-manage their condition or to pursue a healthier lifestyle based on data provided (e.g., sleeping hours, heart beat frequency) and preferences selected by the user, including increased body activity or recommendations concerning regular sleep.It is important to note that, other than the MDCG 2019-11, which are not binding, there are no conclusive guidelines as of now, and naturally no examples of enforcement or relevant court decisions applicable to Rule 11 due to its significant deviances from the framework under the MDD. Therefore, practical appliances will only clarify the continued relevance of Class I classifications when the MDR will be applicable.<h4>CONCLUDING REMARKS</h4>Developers and operators of new stand-alone MDSW not yet placed on the EU market need to brace themselves for the new, more rigid classification system under the MDR, which will likely make more products subject to the direct involvement of the notified bodies. Therefore, obtaining CE markings will become more complex and time consuming. A careful assessment should be made, taking into account the intended purpose and the functions of the stand-alone MDSW and by applying the Amended IMRF Framework. Under certain requirements, stand-alone MDSW already on the EU market and classified as a Class I medical device under the MDD will only be required to comply with the new rules as of May 26, 2024. We will discuss these requirements in more detail in Part 6 of our series of articles on Software as a Medical Device in Europe, available on March 19, 2021.  [1] See Annex IV of the MDCG 2019-11on classification examples.   [2] See Annex IV of the MDCG 2019-11on classification examples.

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

Having shed light on the relevance of the intended purpose of a medical device when determining whether software qualifies as medical devices software (“MDSW”) 

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

Nearly one year after its introduction to the House of Commons, the Medicines and Medical Devices Bill 2019‑2021 (the Bill) was granted Royal Assent on 11 February 2021, becoming law as the Medicines and Medical Devices Act 2021 (the Act). The purpose of the Act is to create a structure for the UK Government to legislate for updates or amendments to our existing laws on human and veterinary medicine, clinical trials, and medical devices. Now that the Brexit transition period has come to an end, the Government views the Act as essential in ensuring that the UK retains its position as a world leader in the life sciences industry and is able to take advantage of innovative medicines and technologies more quickly.During its passage through Parliament, the Act was subject to a number of amendments, including the introduction of: (i) an independent Commissioner for Public Safety, and an overarching objective focused on safeguarding public health; and (ii) public consultations in relation to proposed regulations, and requirements for the Medicines and Healthcare products Regulatory Agency (the MHRA) to lay periodic reports before Parliament. These amendments were made to address concerns in the House of Lords surrounding the wide-reaching powers delegated to the MHRA under the Act.One aspect of the Act that remains largely unchanged, however, is the introduction of new enforcement powers for the MHRA. With these new powers, the MHRA can impose either civil or criminal sanctions for breaches of the Act or any secondary legislation made pursuant to it. These offences can be committed by corporates as well as individuals, including company directors. For more information on the offences themselves and the ways in which the resulting penalties can be defended or avoided, see <a target="_blank" href="https://www.mofo.com/resources/insights/201113-uk-life-sciences-regulation-post-brexit.html">our previous alert</a>.Now that the Act has become law, the MHRA must prepare and publish guidance as to the civil sanctions that can be imposed. In particular, the guidance should provide further information regarding monetary penalties and the MHRA’s power to accept enforcement undertakings in place of criminal conviction or the imposition of a fine.  With the objective of the Act being the safeguard of public health and safety it is, however, likely that financial sanctions will be onerous and tolerance for corporates without robust procedures in place will be low.Although the Act now allows the UK the flexibility to respond quickly to medical advances and developments in medical technology, we note that the UK-EU Trade and Cooperation Agreement does not provide for the mutual recognition of regulatory regimes. It will, therefore, be interesting to see how the UK Government and the MHRA seek to balance a new, robust and evolving regulatory regime with the need to remain commercially viable for multinational pharmaceutical companies, medical devices manufacturers and other affected parties that currently operate in both markets. Stephanie Pong, London Trainee Solicitor, contributed to the drafting of this alert.

galloway_jennifer_blog_150x150.png

galloway_jennifer_common_640x280.jpg

galloway_jennifer_heroretina_2700x1160.jpg

galloway_jennifer_mobileretina_750x1040.jpg

galloway_jennifer_social_600x600.jpg

Of Counsel

Jenny Galloway advises corporate clients and senior executives on a range of complex dispute resolution matters, including general commercial and corporate litigation, investigations and contentious regulatory matters. 

Jenny Galloway

mofolifesciences-uk.jpg

Life Sciences Regulatory Framework Becomes Law Post-Brexit

UK Plans for Robust Life Sciences Regulation Post-Brexit

mofolifesciences-uk

Nearly one year after its introduction to the House of Commons, the Medicines and Medical Devices Bill 2019‑2021 (the Bill) was granted Royal Assent on 11 Febru

Life Sciences Regulatory Framework Becomes Law Post-Brexit

In Part 2 of our <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?utm_source=linkedin_elevate&utm_medium=social">series of consecutive articles</a> on the reformed regulatory framework under the <a target="_blank" href="https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32017R0745">EU Medical Device Regulation 2017/745</a> (“MDR”), which will soon govern medical devices software (“MDSW”) in the EU, we will shed further light on the expansion of the definition of “medical device” and the importance of the intended purpose of healthcare-related standalone software in determining the regulatory requirements of companies offering such software in the EU.<h4>Introduction: The Relevance of the Intended Purpose</h4>As is already the case under 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”), the purpose for which the software is intended to be used is and remains the critical factor when determining the obligations regarding regulatory compliance with the European medical devices regime. The intended purpose establishes whether standalone software is considered a medical device in the first place.[1]In particular with regard to so-called health apps or other apps related to biological functions or wellbeing (e.g., related to fitness, diet, sleeping habits, or mental health), no bright line can be drawn between normal software and MDSW. For example, an app that allows the user to monitor his or her food habits for weight control purposes will qualify as normal software, while the same app might qualify as medical device if the monitoring is intended to be used for prevention of diseases such as metabolic disorders. A standalone software application that is claimed by its manufacturer to be a natural method of birth control and in which the user enters certain parameters (first day of menstruation, body basal temperature, etc.) in order to obtain the fertility window, should qualify as a medical device as it is intended to prevent pregnancy or facilitate conception.The following table highlights some of the distinctions:<table border="1" cellspacing="0" cellpadding="0"><tbody><tr><td width="312" valign="top" style="width: undefined%; height: auto;">Medical purpose</td><td width="312" valign="top" style="width: undefined%; height: auto;">Non-medical purpose</td></tr><tr><td width="312" valign="top" style="width: undefined%; height: auto;">Prevention or diagnosis of disease or injury</td><td width="312" valign="top" style="width: undefined%; height: auto;">Patient medical education (e.g., giving general health tips)</td></tr><tr><td width="312" valign="top" style="width: undefined%; height: auto;">Treatment or alleviation of disease or injury (e.g., giving instructions to alleviate symptoms such as tinnitus)</td><td width="312" valign="top" style="width: undefined%; height: auto;">Monitoring of general fitness (e.g., physical exercise tracker), general health, and general wellbeing (e.g., wellness diary)</td></tr><tr><td width="312" valign="top" style="width: undefined%; height: auto;">Decision support or decision-making (e.g., with regard to therapeutic measures)</td><td width="312" valign="top" style="width: undefined%; height: auto;">Communication or simple search functions (e.g., finding a certain healthcare specialist)</td></tr><tr><td width="312" valign="top" style="width: undefined%; height: auto;">Control of conception</td><td width="312" valign="top" style="width: undefined%; height: auto;">Storing and displaying medical data (e.g., weight or body fat) without any change or analysis</td></tr></tbody></table> In this regard, we want to focus on three changes introduced by the MDR that are particularly noteworthy.<h4>1. Expansion of the Definition of “Medical Device”</h4>The MDR broadens the scope of medical purposes that are covered by adding new specifications to the list of relevant medical purposes. The full list of medical purposes under Article 2(2) of the MDR thus reads as follows (emphasis added to highlight the changes compared to the MDD):<ul><li>Diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease;</li><li>Diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability;</li><li>Investigation, replacement, or modification of the anatomy or of a physiological or pathological process or state;</li><li>Providing information by means of in vitro examination of specimens derived from the human body, including organ, blood and tissue donations; or</li><li>Control or support of conception.</li></ul>For standalone software, in particular, the addition of prediction and prognosis of disease can become relevant, e.g., for software providing healthcare professionals with information on a patient’s future health prospects or likely individual outcomes of a certain therapy. The importance of this addition also becomes palpable when looking at current COVID-19 apps. Based on a person’s recent contacts, such apps often make a prognosis with regard to the risk of the user developing COVID-19, while the app would not be in a position to actually diagnose the infection.<h4>2. Expansion of Relevant Material and Product Life Cycle Approach</h4>The MDR comprehensively includes further material to be considered when assessing the medical purpose. Under current law, according to Article 1(2)(g) of the MDD, “intended purpose” means the use for which the device is intended according to “the data supplied by the manufacturer on the labelling, in the instructions and/or in promotional materials.” In this regard, Article 2(12) of the MDR now also lists sales materials and statements to emphasize that any such information in whatever form given will be relevant. It also includes the specifications made by the manufacturer in the clinical evaluation (regarding the increased importance of the clinical evaluation, as we will describe in Part 4 of this series, available from March 5, 2021), which will require manufacturers to put even greater care on the framing of the intended purpose.In line with the new product life cycle-focused approach of the MDR, it further intends to prohibit any attempts by the manufacturers to expand the intended purpose after the conformity assessment has been carried out. Article 7(d) of the MDR stipulates this expressly and prohibits the use of text, names, trademarks, pictures, or signs in the labelling; instructions for use; or making available, putting into service, and advertising of devices that are not in compliance with the intended purpose for which the conformity assessment was carried out.<h4>3. The Intended Purpose Is Not the Only Factor Qualifying a Product as Medical Device</h4>The MDR introduces in its Annex XVI groups of products (e.g., contact lenses) that irrespective of their intended purpose qualify as medical devices. While these product groups currently are not relevant with regard to standalone software, this may change as Annex XVI will likely be expanded over time.<h4>Concluding Remarks</h4>Even though the changes introduced to the regulation of software by the MDR may seem subtle at first glance, developers and stakeholders in the fields of digital health, fitness, and wellbeing should be aware that more products might be regulated in the foreseeable future. The MDR will make inevitable a careful assessment of the intended purpose of apps and other software products, which must cover every part of their documentation and advertisement. Framing the purpose of MDSW correctly will not only determine the applicability of the MDR but also potentially limit the scope of use for which an app can be marketed. Only a proactive and consistent approach in this regard will prevent any interference by the competent authorities and secure a smooth transition into the future market under the MDR. [1] Software also falls under the MDR’s framework if the software is intended for controlling or influencing the performance of medical devices or is an “accessory for a medical device” within the meaning of Article 2(2) of the MDR. In this series, however, we focus on standalone software.

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

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

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

The COVID-19 pandemic has significantly accelerated the adoption of digital health and virtual care in Europe, as well as globally. Fueled by technological advancement, including in the space of data analytics and AI, <a href="https://www.fiercehealthcare.com/tech/7-predictions-for-how-technology-will-shape-healthcare-2021?_lrsc=24600661-c20a-46c7-b0d4-aa4705e23af1&cid=other-soc-lke" target="_blank">this trend is likely to continue</a>.As with every health-related product or service, manufacturers of software addressing certain health issues must navigate a complex regulatory landscape. In Europe, prior to being placed on the market, software applications must obtain a CE marking when intended to be used for one or more of the following medical purposes:<ul><li>Diagnosis, prevention, monitoring, treatment, or alleviation of disease;</li><li>Diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability;</li><li>Investigation, replacement, or modification of the anatomy or of a physiological process; </li><li>Providing information by means of in vitro examination of specimens derived from the human body, including blood and tissue donations; or</li><li>Control or support of conception.</li></ul>Software also falls under the medical devices regulatory framework and requires CE marking if the software is (i) intended for controlling or influencing the performance of medical devices (e.g., software controlling the dosage of automatically given medication) or (ii) is an “accessory for a medical device” (e.g., software on a smartphone linked wirelessly for data collection to a monitoring medical device).The relevant framework is currently laid out in the EU Medical Device Directive (93/42/EEC, as amended by Directive 2007/47/EC – “MDD”), as transposed in various national laws of the EU Member States, in Germany, for example, the German Medical Device Act (Medizinproduktegesetz).On May 26, 2021, the MDD is intended to be replaced by the <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32017R0745" target="_blank">EU Medical Device Regulation 2017/745</a> (“MDR”). The MDR will provide for a revised and, in certain areas, significantly stricter regulatory framework not only for medical devices in general but also for medical devices software (“MDSW”) in particular. Other than the MDD, the MDR will apply directly in all EU Member States without requiring transposition into national law.The MDR was initially intended to come into effect on May 26, 2020. This date was moved to May 26, 2021, to avoid the chance that medical device companies will be burdened with additional requirements amidst the COVID-19 pandemic.Albeit rumor has it that the EU lawmaker is contemplating a further postponement. Given the time and resources that will be required to comply with the new requirements that lie ahead, it is high time for companies planning to offer new MDSW products or services in the EU to start getting up to speed with the new framework now if they have not already done so.In this series of consecutive articles, we will give a detailed overview on certain key changes that the new MDR regime will bring about for companies that market stand-alone MDSW in Europe.[1] In our upcoming five articles, we will discuss the following issues in greater detail:<ol><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>The new definition of “intended purpose” covers more devices. This includes MDSW for the purpose of “prediction and prognosis” of diseases and health conditions. Furthermore, companies should be aware of the way the intended purpose is determined, as this requires a consistent approach to labelling, use instructions, and promotional material. (Available 2/19)</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>. The new risk categorization regime of the MDR introduces a specific rule dedicated to stand-alone MDSW, according to which many stand-alone MDSWs are expected to be categorized as Class IIa and higher. As a result of that, mere self‑certification will no longer suffice, and there may be a need to update technical documentation. There will, however, still be room for categorization in Class I. (Available 2/25)</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>. In contrast to the MDD, the MDR places more emphasis on the entire life cycle of a MDSW. This approach entails new requirements and an increased level of detail to Quality Managements Systems, Clinical Evaluations, and Technical Data, as well as the reinforcement of the post‑market obligations. (Available 3/11)</li><li><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">Introduction of a Unique Device Identification requirement for MDSW</a>. The MDR introduces a more detailed tracking mechanism. The unique device identification (“UDI”) must be used by any MDSW company. It allows the company and authorities to trace individual devices through their supply chain. The intention here is to make recalls fast and efficient if devices have been deemed a safety risk. Moreover, the MDR aims for a more efficient access to information about approved MDSW through the European Databank on Medical Devices (“EUDAMED”). (Available 3/24)</li><li><a target="_blank" href="https://lifesciences.mofo.com/topics/Software-as-medical-device-in-Europe-new-regulatory-regime-to-enter-into-force-part-6.html">How about Class I MDSW already on the market?</a> MDSW currently classified as a Class I medical device under the MDD, which would be moved into a higher-risk class under the MDR, will only be required to comply with the new rules as of May 26, 2024, if it continues to comply with the requirements of the MDD and there are no significant changes in design and the intended purpose. Guidance on what constitutes significant changes can be found <a href="http://www.doks.nbog.eu/Doks/NBOG_BPG_2014_3.pdf" target="_blank">here</a>. Yet, these MDSWs, too, will be subject to the requirements of the MDR relating to market surveillance and post-market surveillance, vigilance, registration of economic operators, and of devices from May 26, 2021. (Available 4/13)</li></ol>MDSW companies placing or intending to place MDSW on the EU market should be aware of the key changes of the MDR and consider whether these affect their operations in order to ensure a smooth transition from the MDD to the MDR. Read more in our weekly series publications. [1] Note that this article does not address the In Vitro Diagnostic Regulation (“IVDR”); the interested reader can find information <a href="https://www.gov.uk/government/publications/in-vitro-diagnostic-medical-devices-guidance-on-legislation" target="_blank">here</a>.