What are the 6 New Essential Requirements?

Click HERE if you want to receive future “European Regulatory Updates” by email. Just provide your Name, Company, Phone Number, and the email address where you would like to receive updates.

Annex I of the European Medical Device Directive (http://bit.ly/M5MDD) is titled “Essential Requirements.” Most companies demonstrate that their device meets the 13 Essential Requirements (ERs) by creating an Essential Requirements Checklist (ERC). I have no idea what the origin of the ERC is, but you know that regulators love tables and checklists. This particular checklist is so commonly used that the Global Harmonization Task Force (GHTF) included an example of an ERC, called an “Essential Principles Checklist” (EPC) at the end of a guidance document on how to create Summary Technical Documentation (STED) for In Vitro Diagnostic devices (http://bit.ly/STEDIVD)—which is now maintained on the IMDRF.org website.

On September 26, 2012, the European Commission released a proposal for new EU Medical Device Regulations (http://bit.ly/EUProposal). This proposal still includes ERs in Annex I, but there are 19 ERs in the proposal. One regulatory professional recently sent me a follow-up question in response to an audio seminar I conducted in November (). Her question was, “What are the six new ERs?”

A few of the early reviews of the proposal indicated that there were no significant changes, but I have learned the hard way that you should always go to the source and verify the information for yourself (i.e. – Genchi Genbutsu). Here’s what I found:

General Requirements (ER 1-6a)

1. No real change to this requirement.
2. This requirement was reworded to clarify the intent (see Annex ZA of EN 14971:2012 for more info @ http://bit.ly/ISO14971-2012changes).
3. It appears as though the Commission thought the current ER 3 was redundant and the requirement was addressed by ER 1 and ER 5 already.
4. This is now the new ER 3, and the requirement now clarifies how Notified Bodies shall apply this requirement in cases where a lifetime of the device is not stated.
5. This is now the new ER 4, and there is no real change.
6. This is now the new ER 5, and the wording has been clarified.

ER6a is conspicuously missing from the proposed ERs, but don’t get excited. Clinical Evaluations are still required as part of the Technical Documentation in Annex II, Section 6.1c: “the report on the clinical evaluation in accordance with Article 49(5) and Part A of Annex XIII.”

Chemical, Physical & Biological Properties (ER 7)

ER 7.1 has one new requirement: “d) the choice of materials used, reflecting, where appropriate, matters such as hardness, wear and fatigue strength.” ER 7.2 and 7.3 remain unchanged. ER 7.4 has been simplified to what is proposed as the new, shorter ER 9. ER 7.5 is now the new ER 7.4, and the changes reflect the current status of phthalate regulations and similar issues. ER 7.6 is now the new ER 7.5, but there is no change to the content. The new ER 7.6 requires that manufacturers address the risks associated with the size and properties of particles—especially nanomaterials. The changes associated with this section will impact certain device types more than others—such as orthopedic implants.

Infection & Microbial Contamination (ER 8)

ER 8 is still ER 8, but ER 8.1 is now prescriptive regarding design solutions and the current ER 8.2 is now the new ER 10. The new ER 10 is expanded and references the new EU Regulations regarding devices manufactured utilizing tissues or cells of animal origin: Commission Regulation (EU) No 722/2012 of 8 August 2012 (http://bit.ly/AnimalTissueReg). The new ER 8.2 is a new requirement that was an oversight of the MDD, and the new ER 8.7 now clarifies that the labeling must differentiate sterile and non-sterile versions of the product; packaging is no longer an acceptable mechanism for differentiation. The balance of ER 8 remains unchanged.

Construction & Environmental Properties (ER 9)

This ER is now identified as the new ER 11, and this section is expanded. This reflects the emphasis on the need to evaluate the safety of devices with accessories, compatibility with other devices, and the affects of the use environment.

Devices with a Measuring Function (ER 10)

This ER is now identified as the new ER 12, but ER 10.2 from the current Directive appears to be missing. What’s up?

Take a look at the new ER 11. ER 10.2 is now the new ER 11.6.

Protection Against Radiation (ER 11)

This ER is now identified as the new ER 13, but there is nothing new.

Requirements for Devices Connected to or Equipped with an Energy Source (ER 12)

ER 12.1 and 12.1a are now ER 14. This section is specific to software requirements and has more detail than the current Directive. IEC 62304:2006, “Medical device software – Software life cycle processes,” is the Standard that will be expected by Notified Bodies as a reference for ER 14. ER 12.2 through ER 12.6 are now ER 15, but there is nothing new. This Section ER 12.7 and its sub-parts are now addressed by ER 16. ER 12.8 and its sub-parts are now addressed by ER 17.

Information Supplied by the Manufacturer (ER 13)

This is now identified as ER 19: “Label and Instructions for Use.” This section is simplified from ER 13 (i.e. – there are fewer sections), but this ER does not seem to be any shorter. ER 19.1 has sub-parts a-g, and this ER section incorporates the concepts previously addressed by ER 13.1, 13.2, 13.4 and 13.5. ER 19.2 is a new and improved version of the previous ER 13.3 specific to labeling requirements. This labeling section is expanded from sub-parts “a” through “n” to “a” through “q”. The UDI requirement is sub-part “h”. ER 13.6 is now ER 19.3 specific to the instructions for use (IFU). This section is expanded from sub-parts “a” through “q” to “a” through “t”.

The number of sub-parts to ER 19.3 doesn’t reflect the additional requirements for IFUs that are proposed by the Commission. The sub-sections of this part warrant special attention. Items that frequently are found missing from IFUs on the market today include:

1. ER 19.3c – performance intended by the manufacturer
2. ER 19.3h – installation and calibration instructions
3. ER 19.3k – how to determine if a re-usable device should be repaired/replaced
4. ER 19.3m – restrictions on combinations with other devices
5. ER 19.3o – detailed warning information
6. ER 19.3p – information about safe disposal of the device
7. ER 19.3t – notice to user/patient to report adverse events

ER 18 – Use by Lay Persons

This is a short section, but the requirement is new. There are now additional requirements for products intended for use by a lay person. The Risk Management Report, Design Validation, and Clinical Evaluation Report will need to include specific evidence to demonstrate conformity with this ER. The Post-Market Surveillance Plan for these products should carefully verify the accuracy of risk estimates. Post-Market Clinical Follow-up (PMCF) Studies would be challenging in the past, but the prevalence of social media and product registration databases may facilitate conducting PMCF Studies for these products in the future.

Australia & Canada

There is also an EPC that is required by the Therapeutic Goods Administration (TGA) in Australia (http://bit.ly/EPCTGA) and by the Therapeutics Product Directorate (TPD) in Canada (http://bit.ly/CanadianSTED). If you would like to learn more about the Essential Principles of Safety and Performance you should also review the GHTF guidance document on this topic (http://bit.ly/EPSafetyPerf) on the IMDRF.org website. This 2012 version of the document supersedes GHTF/SG1/N041:2005.

I have observed approval of products where the European ERC was submitted in lieu of an EPC for Australia and Canada. I guess they are a little more rationale than some other regulators, but if you have experienced any “push back” regarding this approach please share this by posting a comment or emailing me: rob@13485cert.com.

Advertisement

How do you audit software medical devices?

Software medical devices are used to assist medical professionals. For example, radiologists use software with identifying areas of interest for medical imaging. Do you know how to audit a software company?

When I was trying to find a good song selection for a music video to pair with this blog topic, I thought that the “Digital Man” would be perfect. However, I wasn’t impressed with the selection of videos available. Therefore, I selected this perennial fan favorite:

As a 3rd party auditor, I have had the pleasure of auditing software companies for CE Marking. When you audit a software company for the first time, this forces you to re-learn the entire ISO 13485 Standard. For example, if a company only produces software there is very little to sample for incoming inspection and purchasing records. This is because the product is not physical—it’s software. Clauses of ISO 13485 related to sterility, implants, and servicing are also not applicable to software products. If the software is web-based, the shipping and distribution clauses (i.e. – 7.5.5) might present a challenge to an auditor as well.

The aspects of the ISO 13485 Standard that I found to be the most important to auditing software products were design controls and customer communication. Many auditors are trained on auditing the design and development of software, but very few auditors have experience auditing technical support call centers. When auditing a call center, most of the calls represent potential complaints related to the software “bugs”, system incompatibilities with the operating system or hardware, and use errors resulting from the design of the user interface.

In most technical support call centers, the support person tries to find a work-around for problems that are identified. The problem with a “work-around” is that it is the opposite approach to the CAPA process. In order to meet the requirements of ISO 13485, software companies must show evidence of monitoring and measuring these “bugs”. There must also be evidence of management identifying negative trends and implementing corrective actions when appropriate.

As an auditor, you should focus on how the company prioritizes “bugs” for corrective actions. Most software companies focus on the severity to software operation and the probability of occurrence. This is the wrong approach. Failure to operate is not the most severe result of medical device software failure. Medical device software can result in injury or death to patients. Therefore, it is critical to use a risk-based approach to prioritization of CAPAs. This risk-based approach should focus upon severity of effects upon patients—not users. This focus on safety and efficacy is an essential requirement of the Medical Device Directive (93/42/EEC as modified by 2007/47/EC) and it is a requirement of ISO 14971:2007.

What is the Design Input?

Micky, this is for you.

I have been directly involved in dozens of design projects throughout my career, and during the past three years I have audited 50+ Design Dossiers for CE Marking of Medical Devices. Throughout most of these design projects, I have noticed one common thread—a misunderstanding of design inputs.

ISO 13485 identifies the requirements for Design Inputs. These requirements are:

1. Functional (7.3.2a)
2. Performance (7.3.2a)
3. Safety (7.3.2a)
4. Statutory / Regulatory (7.3.2b)
5. Previous and Similar Designs (7.3.2c)
6. Essential Requirements (7.3.2d)
7. Outputs of Risk Management (7.3.2e)
8. Customer Requirements (7.2.1)
9. Organizational Requirements (7.2.1)

The most common error seems to be the failure to include the outputs of risk management. For those of you that have used design FMEA’s—that’s what the right-hand columns are for. When you identify suggested actions to mitigate risks with the current design, these actions should be translated into inputs for the “new and improved” model.

The second most common error seems to be failure to consider regulatory requirements. There are actually two ways this mistake is frequently made: 1) Canadian MDR’s were not considered as design inputs for a device intended for Canadian medical device licensing, and 2) an applicable ISO Standard was not considered (i.e. – “State of the Art” is Essential Requirement 2 of the Medical Device Directive or MDD).

The third most common error, and the one that drives me crazy, is confusion of design outputs and design inputs. For example: an outer diameter of 2.3 +/- 0.05 mm is not a design input for a 7 French arterial catheter. This is a design output. The user need might be that the catheter must be small enough to fit inside the femoral artery and allow interventional radiologists to navigate to a specific location to administer therapy. Validation that the new design can do this is relatively straight forward to evaluate in a pre-clinical animal model or a clinical study. The question is, “What is the design input?”
Design inputs are supposed to be objective criteria for verification that the design outputs are adequate. One example of a design input is that the catheter outer diameter must be no larger than a previous design that is an 8 French catheter. Another possible design input is that the catheter outer diameter must be less than a competitor product. In both examples, a simple measurement of the OD is all that is required to complete the verification. This also gives a design team much more freedom to develop novel products than a narrow specification of 23 +/- 0.05 mm allows for.

If you are developing a Class II medical device for a 510(k) submission to the FDA, special controls guidance documents will include design inputs. If you are developing a Class IIa, Class IIb or Class III medical device for CE marking, there is probably an ISO Standard that lists functional, performance and safety requirements for the device. Regulatory guidance documents and ISO Standards usually reference test methods and indicate acceptance criteria. When you have a test method and acceptance criteria defined, it is easier to write a verification protocol. Therefore, design teams should always strive to document design inputs that reference a test method and acceptance criteria. If this is not done, verification protocols are much more difficult to write.

In my earlier example, the outer diameter of 2.3 +/- 0.05 mm is a specification. Unfortunately, many companies would document this as an input and use the final drawing as the output. By making this mistake, “verification” is simply to measure the outer diameter to verify that it matches the drawing. This adds no value and if the specifications are incorrect the design team will not know about it.

A true verification would include a protocol that identifies the “worst-case scenario” and verifies that this still meets the design input requirements. Therefore, if the drawing indicates a dimensional tolerance of 2.3 +/- 0.05, “worst-case” is 2.35 mm. The verification process is to measure either a previous version of the product or a competitor’s catheter. The smallest previous version or competitor catheter tested must be larger than the upper limit of the design output for outer diameter of the new catheter.