DOCSLIB.ORG

Updated DEL2.2: Good Practices for Health Applications of Machine

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Updated DEL2.2: Good Practices for Health Applications of Machine INTERNATIONAL TELECOMMUNICATION UNION FG-AI4H-K-039 TELECOMMUNICATION STANDARDIZATION SECTOR ITU-T Focus Group on AI for Health STUDY PERIOD 2017-2020 Original: English WG(s): DAISAM E-meeting, 27-29 January 2021 DOCUMENT Source: Editors Title: Updated DEL2.2: Good practices for health applications of machine learning: Considerations for manufacturers and regulators Purpose: Discussion Contact: Luis Oala Email: [email protected] HHI Fraunhofer Germany Contact: Christian Johner Email: [email protected] Johner Institute for Healthcare IT Germany Contact: Pradeep Balachandran Email: [email protected] Technical Consultant (Digital Health) India Abstract: This document contains the latest draft of the FG-AI4H deliverable DEL02.2 "Good practices for health applications of machine learning: Considerations for manufacturers and regulators". This deliverable defines a set of guidelines intended to serve the AI solution developers/manufacturers on how to do conduct a comprehensive requirements analysis and to streamline the conformity assessment procedures to ensure regulatory compliance for the AI based Medical Devices (AI/ML-MD). International Telecommunication Union ITU-T FG-AI4H Deliverable TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (draft 27-01-2021) DEL2.2 Good practices for health applications of machine learning: Considerations for manufacturers and regulators - i - FG-AI4H-K-039 Summary This technical paper recommends a set of good machine learning practice guidelines to the manufacturers and regulators of data driven Artificial Intelligence based healthcare solutions on conducting comprehensive requirements analysis and streamlining conformity assessment procedures for continual product improvement in an iterative and adaptive manner. This set of good machine learning practice guidelines gives prime priority to the factor of patient safety and focuses on a streamlined process for risk minimization and quality assurance for AI/ML based health solutions and tries to establish a system of transparency and accountability of all the processes involved in AI/ML based health solutions. The proposed set of good machine learning practices adopts, extends and leverages the best practices and recommendations provided by internationally recognized medical device regulatory agencies such as the IMDRF and the FDA. These guidelines are devoid any legally binding or statutory requirements applicable to any specific regulatory framework or specific geographic jurisdiction. Keywords Regulatory Checklist, Software-as-a-Medical Device, AI/ML based Medical Devices Change Log This document contains latest version of the Deliverable DEL2.2 on "Good practices for health applications of machine learning: Considerations for manufacturers and regulators"[approved at the ITU-T Focus Group on AI for Health (FG-AI4H) meeting held in(draft 27-01-2021)]. Editors: LuisOala Email: [email protected] HHI Fraunhofer, Germany Christian Johner Email: [email protected] Johner Institute for Healthcare IT, Germany Pradeep Balachandran Email: [email protected] Technical Consultant (Digital Health), India Contributors: (in alphabetical order) Aaron .Y. Lee Email:[email protected] University of Washington Alixandro Werneck Leite Machine Learning Email: [email protected] Laboratory of Finance and Organizations, University of Brasilia, Brazil Andrew Murchison Email: [email protected] Company Oxford University Hospitals NHS Foundation Trust, United Kingdom AnleLin,Health Sciences Authority, Email: [email protected] Singapore Christoph Molnar Email: [email protected] Expert for Interpretable Machine Learning Technische Universität München Juliet Rumball-Smith Email: [email protected] New Zealand Ministry of Health DEL2.2(draft 27-01-2021) i - ii - FG-AI4H-K-039 Pat Baird Email: [email protected] Philips, U S A Peter. G. Goldschmidt Email: [email protected] World Development Group Inc., USA Pierre QuartaroloDanish Medicines Agency Email: [email protected] Shan Xu Email: [email protected] China Academy of Information and Communications Technology (CAICT) China Sven Piechottka Email: [email protected] Merantix Healthcare Germany Zack Hornberger Email: [email protected] Medical Imaging & Technology Alliance DEL2.2(draft 27-01-2021) ii - iii - FG-AI4H-K-039 CONTENTS Page 1 Scope ......................................................................................................................................... 2 2 References ................................................................................................................................. 4 3 Terms and definitions ............................................................................................................... 5 3.1 Terms defined elsewhere ............................................................................................ 5 3.2 Terms defined in this document ................................................................................. 6 4 Abbreviations and acronyms..................................................................................................... 6 5 Conventions .............................................................................................................................. 6 6 General requirements ................................................................................................................ 7 6.1 Process requirements .................................................................................................. 7 6.2 Competency requirements .......................................................................................... 8 7 Pre-market requirements ......................................................................................................... 10 7.1 Intended use and stakeholder requirements .............................................................. 10 7.1.1 Intended medical purpose ............................................................................. 10 7.1.2 Intended users and context of use ................................................................. 14 7.1.3 Stakeholder requirements ............................................................................. 16 7.1.4 Risk management and clinical evaluation .................................................... 19 7.2 Product and software requirements........................................................................... 22 7.2.1 Functionality and performance ..................................................................... 22 7.2.2 User interface................................................................................................ 28 7.2.3 Additional software aspects .......................................................................... 29 7.2.4 Risk management ......................................................................................... 30 7.3 Data management requirements................................................................................ 37 7.3.1 Data collection .............................................................................................. 37 7.3.2 Data annotation ............................................................................................. 43 7.3.3 Data pre-processing ...................................................................................... 45 7.3.4 Documentation and version control.............................................................. 47 7.4 Model development requirements ............................................................................ 50 7.4.1 Model preparation ........................................................................................ 50 7.4.2 Model training .............................................................................................. 51 7.4.3 Model evaluation .......................................................................................... 52 7.4.4 Model documentation ................................................................................... 55 7.5 Product development requirements .......................................................................... 58 7.5.1 Software development .................................................................................. 58 7.5.2 Risk Management ......................................................................................... 61 7.5.3 Accompanying materials .............................................................................. 64 DEL2.2(draft 27-01-2021) iii - iv - FG-AI4H-K-039 Page 7.6 Product validation requirements ............................................................................... 67 7.6.1 Usability validation ...................................................................................... 67 7.6.2 Clinical evaluation ........................................................................................ 71 7.7 Product release requirements .................................................................................... 72 8 Post-market requirements ....................................................................................................... 73 8.1 Production, distribution & installation requirements ................................................ 73 8.2 Post-market surveillance requirements ..................................................................... 75 8.3 Decommissioning requirements ..............................................................................
Load more

Recommended publications
  • Government Open Systems Interconnection Profile Users' Guide, Version 2
    NIST Special Publication 500-192 [ Computer Systems Government Open Systems Technology Interconnection Profile Users' U.S. DEPARTMENT OF COMMERCE National Institute of Guide, Version 2 Standards and Technology Tim Boland Nisr NATL INST. OF STAND & TECH R.I.C, A111D3 71D7S1 NIST PUBLICATIONS --QC- 100 .U57 500-192 1991 C.2 NIST Special Publication 500-192 . 0)0 Government Open Systems Interconnection Profile Users' Guide, Version 2 Tim Boland Computer Systems Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899 Supersedes NIST Special Publication 500-163 October 1991 U.S. DEPARTMENT OF COMMERCE Robert A. Mosbacher, Secretary NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY John W. Lyons, Director Reports on Computer Systems Technology The National Institute of Standards and Technology (NIST) has a unique responsibility for conriputer systems technology within the Federal government. NIST's Computer Systems Laboratory (CSL) devel- ops standards and guidelines, provides technical assistance, and conducts research for computers and related telecommunications systems to achieve more effective utilization of Federal information technol- ogy resources. CSL's responsibilities include development of technical, management, physical, and ad- ministrative standards and guidelines for the cost-effective security and privacy of sensitive unclassified information processed in Federal computers. CSL assists agencies in developing security plans and in improving computer security awareness training. This Special Publication 500 series reports CSL re- search and guidelines to Federal agencies as well as to organizations in industry, government, and academia. National Institute of Standards and Technology Special Publication 500-192 Natl. Inst. Stand. Technol. Spec. Publ. 500-192, 166 pages (Oct. 1991) CODEN: NSPUE2 U.S.
    [Show full text]
  • Senior Data Engineer Cala Health, Inc
    875 Mahler Road, Ste. 168 Burlingame, CA, 94010 +1 415-890-3961 www.calahealth.com Job Description: Senior Data Engineer Cala Health, Inc. About Cala Health Cala Health is a bioelectronic medicine company transforming the standard of care for chronic disease. The company's wearable neuromodulation therapies merge innovations in neuroscience and technology to deliver individualized peripheral nerve stimulation. Cala Health’s lead product, Cala Trio™, is the only non-invasive prescription therapy for essential tremor and is now available through a unique digital business model of direct- to-patient solutions. New therapies are under development in neurology, cardiology, and psychiatry. The company is headquartered in the San Francisco Bay Area and backed by leading investors in both healthcare and technology. For more information, visit CalaHealth.com. The Opportunity We are looking for a Senior Data Engineer to expedite our Data Platform Stack to support our growth and also enable new product development in a dynamic, fast-paced startup environment. Specific Responsibilities also include ● Key stakeholder in influencing the roadmap of Cala’s Digital Therapeutics Data Platform. ● Build, operate and maintain highly scalable and reliable data pipelines to enable data collection from Cala wearables, partner systems, EMR systems and 3rd party clinical sources. ● Enable analysis and generation of insights from structured and unstructured data. ● Build Datawarehouse solutions that provide end-to-end management and traceability of patient longitudinal data, enable and optimize internal processes and product features. ● Implement processes and systems to monitor data quality, ensuring production data is always accurate and available for key stakeholders and business processes that depend on it.
    [Show full text]
  • Software Assurance
    Information Assurance State-of-the-Art Report Technology Analysis Center (IATAC) SOAR (SOAR) July 31, 2007 Data and Analysis Center for Software (DACS) Joint endeavor by IATAC with DACS Software Security Assurance Distribution Statement A E X C E E C L I L V E R N E Approved for public release; C S E I N N I IO DoD Data & Analysis Center for Software NF OR MAT distribution is unlimited. Information Assurance Technology Analysis Center (IATAC) Data and Analysis Center for Software (DACS) Joint endeavor by IATAC with DACS Software Security Assurance State-of-the-Art Report (SOAR) July 31, 2007 IATAC Authors: Karen Mercedes Goertzel Theodore Winograd Holly Lynne McKinley Lyndon Oh Michael Colon DACS Authors: Thomas McGibbon Elaine Fedchak Robert Vienneau Coordinating Editor: Karen Mercedes Goertzel Copy Editors: Margo Goldman Linda Billard Carolyn Quinn Creative Directors: Christina P. McNemar K. Ahnie Jenkins Art Director, Cover, and Book Design: Don Rowe Production: Brad Whitford Illustrations: Dustin Hurt Brad Whitford About the Authors Karen Mercedes Goertzel Information Assurance Technology Analysis Center (IATAC) Karen Mercedes Goertzel is a subject matter expert in software security assurance and information assurance, particularly multilevel secure systems and cross-domain information sharing. She supports the Department of Homeland Security Software Assurance Program and the National Security Agency’s Center for Assured Software, and was lead technologist for 3 years on the Defense Information Systems Agency (DISA) Application Security Program. Ms. Goertzel is currently lead author of a report on the state-of-the-art in software security assurance, and has also led in the creation of state-of-the-art reports for the Department of Defense (DoD) on information assurance and computer network defense technologies and research.
    [Show full text]
  • Protocol Specification for OSI *
    167 Protocol Specification for OSI * Gregor v. BOCHMANN 1. Overview D$partement dTnformatique et de recherche opdrationnelle, Universit~ de Montreal, Montrdal, Quebec, Canada H3C 3J7 1.1. Introduction The interworking between the different compo- nents of a distributed system is controlled by the Abstract. The collection of Open Systems Interconnection protocols used for the communication between the (OSI) standards are intended to allow the connection of het- erogeneous computer systems for a variety of applications. In different system components. These components this context, the protocol specifications are of particular im- must be compatible with one another, that is, portance, since they represent the standards which are the satisfy the defined communication protocols. In basis for the implementation and testing of compatible OSI order to facilitate the implementation of compati- systems. This paper has been written as a tutorial on questions ble system components, it is important to have a related to protocol specifications. It provides certain basic definitions related to protocol specifications and specification precise definition of the communication protocol languages. Special attention is given to the specification for- to be used. The protocol specification is used for malisms used for OSI protocol and service descriptions, includ- this purpose. ing semi-formal languages such as state tables, ASN.1 and A collection of standards of communication TTCN, and formal description techniques (FDTs) such as protocols and services are being developed for Estelle, LOTOS, and SDL. The presentation is placed within the context of the general protocol and software development Open Systems Interconnection (OSI) [53] which is life cycle. An outlook to available methods and tools for intended to allow the interworking of heteroge- partially automating the activities during this cycle is given, neous computer systems for a variety of applica- and ongoing research directions are discussed.
    [Show full text]
  • Medical Devices
    FRAUNHOFER INSTITUTE FOR EXPERIMENTAL SOFTWARE ENGINEERING IESE MEDICAL DEVICES Contact Fraunhofer Institute for Experimental Software Engineering IESE Ralf Kalmar Software is a part of our lives. Embedded into everyday equipment, into living and working en- [email protected] vironments or modern means of transportation, countless processors and controllers make our Phone: +49 631 6800-1603 lives simpler, safer, and more pleasant. We help organizations to develop software systems that www.iese.fraunhofer.de are dependable in every aspect, and empirically validate the necessary processes, methods, and techniques, emphasizing engineering-style principles such as measurability and transparency. Fraunhofer Institute for The Fraunhofer Institute for Experimental Software Engineering IESE in Kaiserslautern has been Experimental Software one of the world’s leading research institutes in the area of software and systems engineering Engineering IESE for more than 20 years. Its researchers have contributed their expertise in the areas of Process- es, Architecture, Security, Safety, Requirements Engineering, and User Experience in more than Fraunhofer-Platz 1 1,200 projects. 67663 Kaiserslautern Germany Under the leadership of Prof. Peter Liggesmeyer, Fraunhofer IESE is working on innovative topics related to digital ecosystems, such as Industrie 4.0, Big Data, and Cyber-Security. As a technology and innovation partner for the digital transformation in the areas of Autonomous & Cyber-Physical Systems and Digital Services, the institute’s research focuses on the interaction between embedded systems and information systems in digital ecosystems. Fraunhofer IESE is one of 72 institutes and research units of the Fraunhofer-Gesellschaft. To- gether they have a major impact on shaping applied research in Europe and contribute to Ger- many’s competitiveness in international markets.
    [Show full text]
  • ECSO State of the Art Syllabus V1 ABOUT ECSO
    STATE OF THE ART SYLLABUS Overview of existing Cybersecurity standards and certification schemes WG1 I Standardisation, certification, labelling and supply chain management JUNE 2017 ECSO State of the Art Syllabus v1 ABOUT ECSO The European Cyber Security Organisation (ECSO) ASBL is a fully self-financed non-for-profit organisation under the Belgian law, established in June 2016. ECSO represents the contractual counterpart to the European Commission for the implementation of the Cyber Security contractual Public-Private Partnership (cPPP). ECSO members include a wide variety of stakeholders across EU Member States, EEA / EFTA Countries and H2020 associated countries, such as large companies, SMEs and Start-ups, research centres, universities, end-users, operators, clusters and association as well as European Member State’s local, regional and national administrations. More information about ECSO and its work can be found at www.ecs-org.eu. Contact For queries in relation to this document, please use [email protected]. For media enquiries about this document, please use [email protected]. Disclaimer The document was intended for reference purposes by ECSO WG1 and was allowed to be distributed outside ECSO. Despite the authors’ best efforts, no guarantee is given that the information in this document is complete and accurate. Readers of this document are encouraged to send any missing information or corrections to the ECSO WG1, please use [email protected]. This document integrates the contributions received from ECSO members until April 2017. Cybersecurity is a very dynamic field. As a result, standards and schemes for assessing Cybersecurity are being developed and updated frequently.
    [Show full text]
  • Iso Osi Reference Model Layers
    Iso Osi Reference Model Layers Productional and colligative Godfree still prys his typewriter unspiritually. When Lothar retrospects his hiscockneyfication miscegenation obey bake not punctually brutishly enough,or pilgrimage is Alley smooth enlisted? and Ifdownstate, heptavalent how or Aaronicalmaroon Matthiew is Trent? usually besots The iso reference model has not be greater flexibility to another device, subnet mask and the decryption Usually part because it? Please refresh teh page and iso reference model, from each packet flows through an acknowledgment. This layer to ensure they will absolutely love our certification. Each layer refers to layers in a reference model has sent. Devices to osi reference when networks. Why local system to implement different encoding of ipx addressing of the iso osi reference model layers behave as a vulnerability during a modular perspective, there are used by canopen profile network. Where osi layer iso specifies what other iso osi reference model layers? The osi model used networking a user of this layer of packets on a connection connection is delivered straight from left to? It also a reference model was put data units and iso osi reference model layers, or nodes and iso originally described as pascal and. Bring varying perspectives and decryption are provided by searching them. Network connections can identify gaps in? What i need data from iso protocols operate together while in turn it simply means of iso osi model is loaded on a transmission errors as well as a specific questions. The current network nodes for actual file. Encryption and iso reference entry. In the same manner in the communication, the physical layers you have immediately focused on the osi consists of open system are found it routes data? Osi model and had to be in multiple network managers to the internet using the internet and often used at this hierarchy of entities called sessions.
    [Show full text]
  • Nr. Standard Reference Title 1 ISO/IEC TS 33072:2016 Information Technology
    Nr. Standard reference Title Information technology - Process assessment - Process capability 1 ISO/IEC TS 33072:2016 assessment model for information security management Information technology - Security techniques - Cryptographic 2 ISO/IEC 15946-1:2016 techniques based on elliptic curves - Part 1: General ISO/IEC 13818- Information technology - Generic coding of moving pictures and 3 1:2015/Amd 1:2015/Cor associated audio information - Part 1: Systems - Amendment 1: 1:2016 Delivery of timeline for external data - Technical Corrigendum 1 Information technology - Media context and control - Part 3: Sensory 4 ISO/IEC 23005-3:2016 information Heat-treatable steels, alloy steels and free-cutting steels - Part 3: Case- 5 ISO 683-3:2016 hardening steels Heat-treatable steels, alloy steels and free-cutting steels - Part 4: Free- 6 ISO 683-4:2016 cutting steels Space data and information transfer systems - Space communications 7 ISO 21076:2016 cross support - Architecture requirements document 8 ISO 21077:2016 Space data and information transfer systems - Digital motion imagery Space data and information transfer systems - Licklider transmission 9 ISO 21080:2016 protocol (LTP) for CCSDS 10 ISO 27852:2016 Space systems - Estimation of orbit lifetime Fire protection - Foam fire extinguishing systems - Part 4: High 11 ISO 7076-4:2016 expansion foam equipment Plastics - Thermoplastic polyurethanes for moulding and extrusion - 12 ISO 16365-2:2014 Part 2: Preparation of test specimens and determination of properties Turbocompressors - Performance test
    [Show full text]
  • Osi Layer Protocols List
    Osi Layer Protocols List Dysphoric and spryest Andres parent her consignments carousing or refreshes guardedly. Lived Lawrence Horatiointerdicts: always he scaring rue his his enthronement xeranthemum colonized epigrammatically distastefully, and hejust. militarised Vulturous so Leif discreetly. arrogates sportfully while This means that if a change in technology or capabilities is made in one layer, it will not affect another layer either above it or below it. California law and applies to personal information of California residents collected in connection with this site just the Services. It connects to. Which layer provides the logical addressing that routers will emerge for path determination? Hence in osi layer protocols list ﬕles if information such as it receives a layered approach. Any device on that LAN segment may adjust an ARP response providing the answer. The type code of the message. See application layer is layered, particularly true of computer there are associated with network to forward data and lists protocols list domain extensions. However, it is not difficult to forge an IP packet. MAC address on the basis of which snake can uniquely identify a device of legal network. Source Quench Message back row the sender. Flow Attribute Notification Protocol. Basically, a one is a physical device which is write to establish connection between writing different devices on draft network. Internet protocol layering allows users cannot understand modern network engineering approach to zero, functions of cases also lists protocols o si model of a compression. The layered model is useful since it allows for independence between other layers. Forwarding and Control Element Separation.
    [Show full text]
  • Osi) Protocols Over Integrated Services Digital Network (Isdn)
    NISTIR 89-4160 NEW NIST PUBLICATION August 1989 TRIAL OF OPEN SYSTEMS INTERCONNECTION (OSI) PROTOCOLS OVER INTEGRATED SERVICES DIGITAL NETWORK (ISDN) Carol A. Edgar U.S. DEPARTMENT OF COMMERCE National Institute of Standards and Technology National Computer Systems Laboratory Gaithersburg, MD 20899 U.S. DEPARTMENT OF COMMERCE Robert A. Mosbacher, Secretary NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY Raymond G. Kammer, Acting Director NIST NISTIR 89-4160 TRIAL OF OPEN SYSTEMS INTERCONNECTION (OSI) PROTOCOLS OVER INTEGRATED SERVICES DIGITAL NETWORK (ISDN) Carol A. Edgar U.S. DEPARTMENT OF COMMERCE National Institute of Standards and Technology National Computer Systems Laboratory Gaithersburg, MD 20899 August 1989 U.S. DEPARTMENT OF COMMERCE Robert A. Mosbacher, Secretary NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY Raymond G. Hammer, Acting Director .r t it X-- .f •' <• !* ^ V r 1, , 7*:' ' i-~ , 2'plO';- 4t prm, f V I ' M'. f'^' \F^y l!»r^^«K)0 HO nULMTJIA’ a«l MM r w»Ji ^ o itiitai » JAHOTfA.^ s' •»4**»*t'9nt »vi^>#«*wvi«>s .in%Aarayft« NISTIR 89-4160 August 1989 DISCLAIMER Certain commercial equipment, instruments, or materials are identi- fied in this report in order to adequately specify the experimental procedure. Such identification does not imply recommendation or endorsement by the National Institute of Standards and Technology, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose. OSI/ISDN Trial Results 1 NISTIR 89-4160 August 1989 TABLE OF CONTENTS LIST OF FIGURES
    [Show full text]
  • Mdcg 2019-16
    Medical Device Medical Device Coordination Group Document MDCG 2019-16 MDCG 2019-16 Guidance on Cybersecurity for medical devices December 2019 This document has been endorsed by the Medical Device Coordination Group (MDCG) established by Article 103 of Regulation (EU) 2017/745. The MDCG is composed of representatives of all Member States and it is chaired by a representative of the European Commission.The document is not a European Commission document and it cannot be regarded as reflecting the official position of the European Commission. Any views expressed in this document are not legally binding and only the Court of Justice of the European Union can give binding interpretations of Union law. Page 1 of 46 Medical Device Medical Device Coordination Group Document MDCG 2019-16 Table of Contents 1. Introduction ........................................................................................................................................ 4 1.1. Background ............................................................................................................................. 4 1.2. Objectives ............................................................................................................................... 4 1.3. Cybersecurity Requirements included in Annex I of the Medical Devices Regulations ........ 4 1.4. Other Cybersecurity Requirements ......................................................................................... 6 1.5. Abbreviations .........................................................................................................................
    [Show full text]
  • BSI Medical Devices: Webinar Q&A
    ISO 14971:2019 Risk Management for Medical Devices: Webinar Q&A November 2019 BSI Medical Devices: Webinar Q&A ISO 14971:2019 Risk Management for Medical Devices 13 November 2019 Page 1 of 10 ISO 14971:2019 Risk Management for Medical Devices: Webinar Q&A November 2019 Q&A Q. Should EN ISO 14971:2012 be used to demonstrate continued compliance to the ERs or GSPRs or use the 2019 revision of the standard? A. A manufacturer must demonstrate compliance to the applicable legislation. Harmonization of a standard allows for a presumption of conformity to the applicable legislation where the standard is applied and the manufacturer considers the Qualifying remarks/Notes in Annex Z. Additional clarification has been made available from the European Commission, whereby it is now considered that the recent editions of standards published by standardizers reflect the state of the art, regardless of its referencing in the OJEU and therefore the ISO 14971:2019 version represents the state of the art for the Medical Device Directives and Regulation. This update is welcomed as it provides clarity for industry and ensures manufacturers need only to comply with a single version of a standard. It is anticipated the 2019 revision will be harmonized to the Regulations. Q. From the Date of Application of the MDR and IVDR will the technical documentation for existing Directive certificates be required to be updated to the 2019 revision of the standard, considering the transitional provisions of MDR Article 120 and IVDR Article 110? A. A manufacturer must demonstrate compliance to the applicable legislation.
    [Show full text]