EU Commission promised 20 Designations

12 Notified Bodies Designated to MDR (9) & IVDR (3*)

*All 3 IVDR Notified Bodies have MDR designation as well, so that can be counted as double counting. It depends on your perspective.

2 NB’s are likely to be “de-designated” (not sure of the proper term yet) end of Jan 2020 based on Brexit. That would be BSI Assurance UK Ltd.

The EU Commission has promised more NB’s to be designated in the 1st quarter of 2020. Let’s hope this will get us to at least 20 NB’s.

Two last-minute Christmas presents were BSI Group Netherlands IVDR and Medcert’s MDR designations on 24 & 25 Dec respectively.

Few products have been CE marked to the MDR that have gone through a NB review process. Typically the process is taking at least a year or more. Your quality system and product files need to be reviewed.

You are running out of time with the transition only about 5 months away.

Not all NB’s have full coverage of the NANDO codes so check the NANDO database (MDR link) or check with your NB.

May you have a Happy, Safe, & Prosperous New Year and may your medical device be CE Marked under the MDR in the New Year.

If you are reading this post my guess is you already know the proposed MDD regulations are contentious and that there is some major changes proposed some good and some not so good. 

The later occurred a couple weeks ago when the Rapporteur Mrs. Roth-Behrendt proposed in a draft report for the MDD regulations.  As Eucomed states “The draft report is a step backward for patients, healthcare systems and Europe.”  The reason is the report calls for “a shift towards a centralised pre-market authorisation system which if carried through to the final legal text will confront patient in Europe with unnecessary delays of lifesaving medical devices reaching them without improving safety.”  The system would create a “enormous bureaucratic system with no benefits.”   Note, this is not a final report so there is a ways to go before we know if this will be finalized as is or modified. 

To get more information and perspective from these organizations please read on the posts and articles: Erik Vollebregt excellent article on the draft report detailing what the changes are; a Guest blog post on Erik Vollebregt medicaldeviceslegal website titled “no enhanced patient safety resulting from rapporteur Roth-Behrendt’s proposal”; Eucomed’s position and understanding of the Rapporteur ‘s draft report; a blog post by the CEO of MedTech Europe, EDMA, & Eucomed in regard to draft report for the MDD; MedTech Europe story on “European Parliament’s ENVI Committee releases draft reports on MDD and IVDD; and Where the EU system for medical devices is and needs to go.

We hope these articles help you understand where the process stands and help you form your own opinions.  From there where you go is up to you but know we will keep sending you updates on this process as we find relevant information to pass on as this process is critical to the survival of the European Medical Device Market.

MEDDEV 2.12-1 Guidelines on a Medical Devices Vigilance System was updated in January 2013.  The revised guidance is applicable as of July 2013.   The revision contains clarifications rather than significant changes.

Download the MEDDEV 2.12/1 revision 8 Guidelines on a Medical Device Vigilance System effective July 2013.  An unofficial Comparison of MEDDEV 2.12/1 from revision 7 to revision 8 can be downloaded, as well. 

Changes include:

• Clarification that, in addition to IVD’s, indirect harm can be from:
  • diagnostic devices,
  • consequence of the treatment of cells (e.g. gametes and embryos in the case of IVF/ART devices) or organs outside of the human body that will later be transferred to a patient, or
  • software qualified as medical devices (e.g., incorrect information generated by software).
• Reinforcement that, when there is doubt, a report should be submitted.
• Clarification that, regardless of how a lack of performance to labeled specifications is identified (field report, in-house testing, etc.), if the issue might lead to or might have led to death or serious deterioration in the state of health associated with the use of the device and the issue impacts a product that has already been placed on the market then a field safety correct action (FSCA) must be initiated.
• Adds “absence of treatment” as an indirect harm that must be considered.
• Indicates that a National Competent Authority should consult the manufacturer or the manufacturer’s European Representative before forwarding a National Competent Authority Report (NCAR) to fellow National Competent Authorities.
• Updates to reporting formats from the MEDDEV website are below in the formats that they provide them in:

Manufacturer Incident Report(971 KB) 
How to use the MIR(13 KB) 
Field Safety Corrective Action(2 MB) 
Trend Report(151 KB) 
Periodic Summary Report(192 KB) 
MIR and FSCA xml files(2 MB)  

Actions to consider:

• Review your MEDDEV procedure(s) to ensure that:
  • Any source of indirect harm will be considered and, if such could result in harm, will result in submission of an incident report.
  • Actions taken to reduce risk of death or serious deterioration in the state of health associated with the use of a device that is already placed on the market will be reported through a Field Safety Corrective Action Report.
  • “Absence of treatment” is an indirect harm that will be considered when making a reporting decision.
  • Where there is doubt, a report will be submitted.
  • Referenced forms reflect the current versions and requirements for completion.
• Review the contract with your European Representative to ensure that it is clear on how the company expects the EU Rep to respond to a request for comment on a NCAR.

Many thanks to Helene Spencer to highlighting the new revision (and for indicating that, with a little work, it is possible to create an unofficial redline).

If you need assistance with this or other issues, please contact us at Leo@EisnerSafety.com.  As a reminder, you can access a full list of MEDDEV’s from the MEDDEV guidance website .

I (as a medical device consultant, US TAG member of IEC SC 62A & 62D & Convener of SC62D JWG9 {IEC/ISO/AAMI/CENELEC 80601-2-58} and a past Notified Body Auditor) am really pleased to see the extremely hard work that has gone into this document and also in the value that it will pass on to all the stakeholders.  There are many stakeholders that were involved in this process including Notified Bodies, NB-MED EN 62304:2006 issues team (Thank you for your hard work.), NB-MED, COCIR (European Coordination Committee of the Radiological, Electromedical and Healthcare IT Industry), Manufacturers, OEMs, Standards Developers for EN & IEC & other national standards bodies, Test Houses, Consultants, other countries regulatory bodies (i.e. FDA, Health Canada, etc.) and more.  By use of so many different stakeholders that submitted some of these and other questions this document has a much more consistent view on the implementation issues with the complexity of the topic of medical device software.  

This document is good for learning about your specific implementation issue(s) or if you have the time I would highly recommend reading the whole document, as this will help you understand the intricacies of some of the situations of implementing EN 62304 with respect to the Medical Devices Directives (I’m sure there are more issues but a good portion have been captured by this first version).  I believe this document would be of great help to implement similar guidance documents for many other national medical device regulatory agencies around the world for IEC 62304:2006 (or their national version of the standard).

The Table of Contents gives a good glimpse into the realm of the issues covered in this document and covers the following topics.  I also provide a further glimpse into the document by summarizing some of the specific issues within those sections (these are the indents furthest to the right):

• Introduction (background of the purpose, rationale, the main team members, and how to provide more feedback on the document)
• Abbreviations (Section 1)
• Questions and Answers (Section 2 – Heading of sections 2.1 – 2.7)
• Scope of EN 62304 (Section 2.1)
• Goes into various different scenarios and discusses the implication and implementation issues around these scenarios: such as SAAS, Embedded software including FPGA’s (a hotly contested issue) with single chip computers, Hardware Description Languages specifying FPGAs, Stand alone software, Medical apps, Excel macros, Open & closed systems, Internet or cloud based, Server based systems, Network devices.  In addition to this list of scenarios this section also goes into questions about certification; is Validation included in this standard & if not where does it get covered; what are the expectation of the Notified Bodies with regard to the standard; can you use only part of the standard; why do class A software to EN 62304; what is IEC 82304 about (software only products); among other questions.
• Placing Software as Medical Device on the Market (Section 2.2)
• Explain ‘placing medical device (in this case software or software {s/w} as part of a system) on the market’ in EU if EN 62304 is sufficient, by itself to do this; can I change my intended use and avoid these EU guidelines and regulations; Conformity Assessment routes of the MDD; other countries acceptance / requirement of the standard; can you sign-off on documents electronically; classification of software as a MEDICAL DEVICE; how do Notified Bodies (NB’s) confirm compliance to the standard; among other questions.
• Life-cycle Processes (Section 2.3)
• If s/w development is an outsourced activity what does NB expect; does this std have an equivalent expectation to requirements such as those addressed in FDA Part 11 (Electronic Records & Signatures) in the US; details on the review process at the end of each iteration when updated versions are available during the design and development of the software; does the std require a specific development process; how split up the requirements/responsibilities of the std between the manufacturer and s/w sub-contractor; how do the maintenance activities in the std relate to ISO 20000/ITIL; what are the artifacts (documents) required by EN 62304; at what level does the Problem Resolution Process apply; does software refactoring require a formal change request; what to include in the Technical File to show compliance with EN 62304; how can agile processes be EN 62304 compliant; among other questions.
• Risk Assessment and Risk Management (Section 2.4)
• How deal with risk control measures; when & why can the safety class of a s/w SYSTEM be reduced; how use ISO 14971 with EN 62304; explain Hazard, Cause, Sequence of Events in the context of software; when should we expect additional Software Hazard Analysis guidance within EN 62304; among other questions.
• Classification and Segregation (Section 2.5)
• What is segregation and how do I prove effective; use of a specific class(es) of s/w using COTS (commercial off-the-shelf) what criteria used; how does severity under intended use relate to s/w safety class; is s/w class optional; can you downgrade the classification of the system without a fully hardware protective system; does the compiler need to be classified under EN 62304; how are development platforms & tools related to s/w safety class; relation between Risk Analysis at System level & S/W Safety Classes; explain how the 3 safety classification in the std differ from the FDA’s 3 levels; correlate IEC 61508 SIL levels to EN 62304 safety classifications; s/w classification is a real issue with big implications; among other questions.
• Specifications, testing and tools (Section 2.6)
• I’m a manufacturer of medical devices – how do I document my requirements and tests; web-based medical s/w – does the std have specific requirements related to digital cert’s, (http or https) server requirements; in regard to the std how deal with risk analysis and functional specs; appropriate level of granularity of requirements as design input, design description; which (if any) of the tracing requirements are meant to be bi-directional; questions around deployment of the s/w; what is required of open source code from the std; among other questions.
• SOUP (Software of Unknown Provenance) and Legacy Software (Section 2.7)
• How assess & qualify suppliers of SOUP s/w, when the s/w hasn’t been developed for incorporating into a medical device; what testing & documentation does EN 62304 require for SOUP to meet the std; s/w that is either stand-alone or embedded which was designed prior to publication of EN 62304 but still being placed on the market (legacy product) – what needs to be done; if legacy s/w needs significant change, what processes & documents are required to achieve &/or maintain compliance with EN 62304 and when are changes considered significant;
• References (No Section Number – just after Section 2.7)
• Software Problem Resolution Process (Annex 1)
• Helpful diagram – There are several entry points to the problem resolution process, both during development and maintenance of the software (refer to question 2.3.12).
• SOUP selection, assessment & qualification (Annex 2)
• Flowchart & text to explain an example
• Traceability (Annex 3)
• The 3 flowcharts show an overview of the dependencies which need to be traced according to EN 62304 for all 3 classes – refer to note in bottom left corner of page to know which class the flowcharts apply to (refer to question 2.6.7).
• Position paper on direct diagnosis (COCIR, 2011) (Annex 4)
• As the different stakeholders may interpret this term differently, COCIR and EUROM VI wanted to share their understanding of the term “direct diagnosis”. (Refer to question 2.5.13)

Click on the weblink to see the initial request for questions that we posted on our website 26 May 2012.  To see the posting please go to http://www.eisnersafety.com/do-you-know-how-to-use-en62304-med-dvc-sw-life-cycle-as-implemented-under-themdd-aimdd-doc/

The European Competent Authorities have formed a Central Management Committee (CMC) to achieve greater consistency in the interpretation and implementation of the requirements related to the medical devices sector (MDD, AIMDD & IVDD).  The CMC has issued decisions that need to be considered and implemented by medical device manufacturers.You can find the decisions at http://www.cmc-md.eu/decisions.html.  Four decisions have been issued to date:

1.     Classification and Boderline Queries (23FEB2011) – States classification decisions along with rationales for:

– Wound irrigation solutions containing antimicrobial agents (Class III under rule 13)
– System to determine bacterial contamination in blood products (falls under the IVDD)
– Qualification of Gallipots as medical devices (not a medical device)

2.     Notified Body Best Practice Guides (23FEB2011) – This does NOT affect manufacturers.  It lists the Notified Body Operations Group (NBOG) Best Practice Guides (NBP) and states that all notified bodies are expected to follow these best practices.

3.     Address of the Manufacturer and EU Representative (issued 23Feb2011, updated 7JUN2011) – The ‘address of the manufacturer’ as required in the Essential Requirements on the labels and instruction for use, is the address of the registered place of business of the legally responsible manufacturer and shall include:

– street/road,
– number/house/floor,
– postal code
– city
– state/region and
– country

The same details have to be provided for the address of the authorized representative.
NOTE:  This is more extensive that what the FDA typically requires for an address.

4.     Readability of Instructions for Use (14MAR2012) – It must be assured, that patients and professionals may use the devices as intended by the manufacturer and any ambiguities with regard to the proper and safe use due to deficiencies in the readability of IFUs are avoided.  To that end:

a.     Appropriate checks should be performed by the manufacturer on suitable samples of target users whether IFUs are  really readable and assure proper and safe use of the device.  This includes consideration of font size, quality of translations, and understandability of texts and graphics.
b.     Post-market surveillance procedures have to be sensitive to any indications of bad readability via vigilance or other channels and to any necessary corrective measures.
c.     Special care has to be taken to enable users to properly identify changes to the previous version of the IFU on the basis of a risk assessment.

As dates/revisions are not posted with the document titles, it may be difficult to determine at-a-glance if the decisions have been updated.  Please take care when checking for updates that you inspect the document of interest.

Notified Bodies have been asked to audit these particular points.  You should anticipate that some or all of these issues will be reviewed during your next audit.

If you have any questions on this matter please feel free to contact us at Leo@EisnerSafety.com.

A request for practical questions and issues has just been launched and the invitation letter for FAQ on EN62304 (a short 2 page document) and publication of the FAQ is expected by end of September 2012.  The request document is asking for your questions and any proposed answers (if you have those too) to be submitted by the end of May 2012 so you better hop on the bandwagon and get those off to the e-mail address of FAQ62304@VDE.com.  I think some of these dates may slip a little but that is not confirmed yet.  If I get confirmation of any changes in dates I will advise as soon as I can.

This may sound familiar as this is a similar process to the FAQ document that was issued in Jan/Feb of this year for the EN 60601-1, 3rd ed. Implementation FAQ document.