EU MDR PMCF: To Waive or Not to Waive

Posted by Kevin Randall In CE Mark, EU MDR 0 comment

July 29, 2021

EU MDR PMCF: To Waive or Not to Waive

When is PMCF Required?

When is PMCF Required? Do “PMCF” if, after proper premarket clinical evaluation, there remains residual risks and/or uncertainty about long-term clinical performance that may impact the benefit/risk ratio. If PMCF is indicated, then be sure the PMCF Plan contains the various design elements prescribed by EU MDR Annex XIV Part B sections 6.1 and 6.2. Be sure to understand that per EU MDR Annex XIV.6.2(b) and Article 74, the terms “PMCF Study” and “PMCF Investigation” appear to be interchangeable, and mean a specific type of PMCF, namely, a prospective or retrospective post-market clinical investigation. PMCF “Studies” / “Investigations” need to ensure the high quality of the collected clinical data by following principles of scientific rigor, accuracy, legibility, and completeness. Refer to MEDDEV 2.12/2 and MDCG 2020-7 for further guidance about those most rigorous types of PMCF. In contrast, understand also that the term “PMCF” is a general umbrella term for all types of PMCF, thus encompassing clinical investigations (a.k.a., PMCF “Studies”/”Investigations”) as well as other general types of PMCF (such as PMCF based on literature, reactive PMS data, etc.) that aren’t prospective clinical investigations.

The Myth that the EU MDR Doesn’t Allow Waiver of PMCF:

There’s a common myth that the EU MDR doesn’t allow waiver of PMCF. In truth, we can waive PMCF if the long-term safety and clinical performance are already known from previous use of the device, or where other appropriate post-market surveillance activities would provide sufficient data to address the risks. Prepare a PMCF waiver stating the basis for the decision to waive PMCF and setting a schedule for periodic reconsideration of the waiver. I still rely on MEDDEV 2.12/2 for further guidance about PMCF waiver.

I would beware of PMS / PMCF systems, assertions, training, or other paradigms that universally demand PMCF for all cases. Such an approach is not in alignment with the EU MDR, and is certain to unnecessarily escalate the cost, complexity, and burden of that aspect of a company’s EU MDR objectives.

To begin with, be sure not to discount that there is longstanding European historical framework and precedent for waiver of PMCF [see MEDDEV 2.12/2 (for the MDD)]. Indeed, I’ve successfully leveraged such waivers repeatedly with NBs under the MDD without objection.

Fast forwarding to the EU MDR era, you may remember my prior Forum explanations of how the EU MDR considers PMCF to be part of PMS. As covered in my prior Forum posts on the topic and in my white paper “Navigating PMCF and its Mysterious Relationship to PMS and Clinical Evaluation in EU Regulation 2017/745” (email info@complianceacuity.com for a copy), PMS is always required by the EU MDR, but not PMCF. Indeed, the EU MDR’s mandatory PMS plan requirements in Annex III.1.1(b) final indent require that the PMS plan contain a PMCF plan as referred to in Part B of Annex XIV, or a justification as to why a PMCF is not applicable. This has been echoed by the MDCG in 2020-7 which provides for a manufacturer’s “…justification in relation to non-performance of PMCF…“.

The option for PMCF waiver is clearly and repeatedly stated by the EU MDR, such as:

Annex II.6.1(d) and Annex III.1.1(b) (applicable to all devices)
Annex IX.2.1 eighth and ninth indents (available as an option for Annex IX devices, which, by the way, could encompass devices all the way up through class III)].
Annex VII.4.5.5 directing Notified Bodies (NB) to make way for PMCF waivers during conformity assessments.
Annex VII.4.6 directing NBs to consider the adequacy of the manufacturer’s PMS plan including a review of the need (or lack thereof) for a PMCF plan.
In addition is the provision for possible exemption from the need for any clinical data at all(yes you heard me right) in Article 61.10 (born from the same provision in MDD Annex X) which seems by default to, in such cases, waive the need for PMCF. (I actually had a prominent NB once encourage me to pursue that route instead of doing a clinical evaluation based on clinical data!).

Time and again under the EU MDR I’ve continued proving the integrity of these assertions via successful EU MDR third-party conformity assessments of Technical Documentation using PMCF waivers. So, based on historical MDD conventions along with their reiteration in specific MDR provisions, it seems that the EU MDR clearly intends to maintain the longstanding precedent of permitting PMCF waiver. This is quite sensible in light of the aforesaid unique purpose of PMCF. Indeed, deploying such a rigorous form of PMS is clearly unnecessary for realizing overall PMS goals for devices where other less-rigorous forms of proactive and reactive PMS would sufficiently guard public health. I expand further on this topic in my aforesaid white paper.

FDA MDUFMA Small Business Determination (SBD) at the Pre-Revenue Stage

Posted by Kevin Randall In FDA, Uncategorized 0 comment

July 27, 2021

FDA MDUFMA Small Business Determination (SBD) at the Pre-Revenue Stage

Before addressing FDA’s MDUFMA fees and SBD program for a firm’s premarket submission when at a pre-revenue / premarket stage, my suggestion is to first remember that if a product clearance or approval [510(k) clearance, PMA approval, etc.] hasn’t happened yet, and assuming that the Sponsor is not engaged in other activities triggering the FDA establishment registration requirement, then the Sponsor should be sure it hasn’t unnecessarily registered its establishment. This is because FDA instructs establishments not to register at the pre-approval stage. Avoiding unnecessary establishment registration will save $5,546 / year (in today’s MDUFMA dollars) which could really add up to a lot of savings given that product development and FDA market authorization campaigns can often be multi-year efforts.

Regarding a firm’s lack of having yet submitted its first Federal U.S. income tax return, remember that section 738(d)(2)(B)(iii) of the Act is, as far as I know, still in effect and includes a bridging provision for firms that haven’t yet submitted their first Federal income tax return. That provision says that, in the case of an applicant that has not previously submitted a Federal income tax return, then the applicant and each of its affiliates shall instead demonstrate the “small business” evidence via submission of a signed certification in the English language from the national taxing authority of the country in which the applicant or, if applicable, affiliate is headquartered, certifying that the applicant or affiliate meets the criteria for a “small business”. Firms need to be sure to give due consideration to this bridging provision when at a pre-revenue / pre-taxation stage.

However, the Act’s section 738(d)(2)(B)(iii) bridging provision may not need to be used at all even though seemingly so at first glance. Indeed, many corporations must submit periodic Federal income tax returns (e.g., Form 941 QUARTERLY Federal Tax Return) during the year leading up to the annual tax return. Such periodic returns are in fact official Federal income tax returns. Accordingly, leveraging such periodic Federal tax returns may also be a viable strategy, specifically, by submitting some or all of the year’s periodic Federal income tax returns in order to officially and statutorily demonstrate that year’s current Federal income status. Some discussion with the Agency may be needed for that strategy in order to determine if the Agency interprets the Act’s phrase “most recent Federal income tax return for a taxable year” to only mean an annual tax return, or if that could also be interpreted to mean the current year’s Federal income tax returns to date. If needed, I wouldn’t hesitate to assert with the Agency that a compilation of the year’s periodic Federal income tax returns would meet the statutory criterion “most recent Federal income tax return for a taxable year” called for by the Act. And it seems that FDA would be amenable to that in light of its webpage guidance stating that if the firm has been in business for less than a year, it can provide the FDA with a copy its U.S. income tax return for a period of time that’s less than 1 year. FDA says that the dates encompassed by the partial-year return need to be identified on the tax return. For that scenario, FDA also asks that the firm provide documentation (such as Articles of Incorporation) identifying the business’s formation date in order to further justify the lack of a full year’s tax return. FDA also says the firm may submit a personal income tax return if needed, where the personal return must identify the submitter’s business and gross receipts or sales under Schedule C of the Form 1040.

Finally, don’t forget that there is a one-time waiver of the MDUFMA PMA fee for a Sponsor’s inaugural PMA pursuant to section 738(d)(1) of the Act.

EU MDR Strategy for Configurable Software

Posted by Kevin Randall In CE Mark, EU MDR 0 comment

July 22, 2021

EU MDR Strategy for Configurable Software

For my clients that manufacture software-only medical devices, I have sought and implemented what I feel is the ideal: The software design and architecture are such that there is one executable software file, but that can be configured via licensing to turn various modules on or off. In this approach, all modules are always present in the software, yet not always turned on. For the purposes of EU MDR conformity, this means there is one product, and thus one DoC, one NB certificate, and one technical documentation file. The different licensing configurations are handled in the software and technical documentation via software installation controls. This approach avoids the hassle of applying the EU MDR’s requirements for “accessories” (i.e., medical devices in their own right), such as the typical need for accessories to have dedicated (usually separate) technical documentation, labeling, DoCs, and/or NB certificates.

Noteworthy parts of the EU MDR’s definition [see Article 2(2)] for “accessory” are that a) it’s an article which intrinsically is not itself a medical device [i.e., it’s just a widget that doesn’t intrinsically meet the EU MDR definition in Article 2(1)]; and b) the main software medical device can’t function as intended (i.e., as labeled, advertised, etc.) without the “add-on”. If the “add-on” doesn’t meet these criteria, then it’s not an “accessory”. Instead, it would either be part of the main medical device software or else a separate medical device in its own right providing supplemental features/functionality or else or else a non-medical (e.g., an EU MDR preface item 19 general purpose, life-style, well-being, etc.) device all together. In the approach I’ve modeled above in my first paragraph, all of the software modules and corresponding code, whether turned on or off, are still part of the same software medical device and executable file.

If on the other hand the “add-ons” are a) actually add-ons in the truest sense, meaning that they are separated software files/patches/code; and either b1) they actually meet the formal definition of “accessory” [meaning that they don’t intrinsically meet the definition of medical device yet enable the main software medical device to function as intended (rather than just providing supplemental features/functionality)], or b2) they just provide supplemental medical device features/functionality, then the manufacturer would typically be stuck handling such add-ons as “accessories” (i.e., as devices in their own right) or as separate medical devices altogether, where dedicated (typically separate) technical documentation, labeling, DoC, certificates, etc., would be required.

EU MDR Changes to MDD DoC under EU MDR Article 120

Posted by Kevin Randall In CE Mark, EU MDR 0 comment

July 22, 2021

EU MDR Changes to MDD DoC under EU MDR Article 120

When considering the requirements for revising an MDD (or EU MDR) Declaration of Conformity (DoC) associated with device changes (whether significant or nonsignificant), it’s important to know that there must always be a valid DoC that accurately represents required details about the subject device’s current state of conformity. Indeed, under the MDD (by way of the EN ISO/IEC 17050 series) and the EU MDR alike, manufacturers are required to continuously update the DoC to assure it remains accurate.

Accordingly, if any change is made to an MDD-certified device to be placed on the market after 26 May 2021 [the EU MDR Date of Application (DoA)] under EU MDR Article 120’s transitional provisions, then the subject device’s Declaration of Conformity (DoC) must be revised as needed if the nature of the change impacts the accuracy of the original declaration.

As we all know, the MDD and EU MDR both generally require that the Notified Body (NB) be informed about significant changes as part of updating the DoC and technical documentation. But if the change truly is nonsignificant, then the MDD and EU MDR permit the DoC and technical documentation to be updated without notification to the Notified Body (NB). That said, be sure to carefully review the NB contract, as some NBs may nonetheless demand to be somehow informed even for nonsignificant changes.

Examples of changes that would directly affect the accuracy (and thus require revision) of the DoC include but are not limited to address changes, standard edition changes, part numbers obsoleted, part numbers changed, and others. Some of these might turn out to be either significant or nonsignificant depending on the associated particulars. So “be sure you’re sure” about whether the change is significant or nonsignificant.

Regarding the clerical aspect (e.g., the form or format) of the revised DoC, it’s noteworthy that the EN ISO/IEC 17050 series has traditionally and normatively given manufacturers the liberty to decide what format suits them best even though it informatively offers an example format. The EU MDR has not withdrawn such liberty. Accordingly, to assure DoC accuracy, it seems that manufacturers could either append an amendment (e.g., via memo) pursuant to EN ISO/IEC 17050-1 clause 6.2 or EU MDR Annex IV.9, or else create a new DoC altogether. I prefer the latter, as the memo-approach seems clunky and ripe for errors and omissions. Either way, be sure that the expiry date of the DoC remains in alignment with Article 120’s cut-off dates if such changes are made for the context of EU MDR Article 120 transitional provisions.

ISO 13485 QMS Planning vs. Quality Plans

Posted by Kevin Randall In Canada, CE Mark, EU MDR, ISO 13485, ISO QMS 0 comment

July 19, 2021

ISO 13485 QMS Planning vs. Quality Plans

I think it’s important to remember that the general quality management system planning and set-up called for by ISO 13485 clause 5.4.2(a) is fundamentally distinct from clause 7.1’s product/project/object/output-oriented planning. If they were the same, then ISO TC/210 would not have separated and distinguished clauses 5.4.2(a) and 7.1.

Clause 5.4.2(a) general quality management system planning is aimed at the more fundamental quality management system setup, implementation, and maintenance of clause 4.1. By contrast, ISO TC/210 has traditionally maintained and currently maintains that a clause 7.1 “quality plan” is instead a product/project/object/output-oriented plan generated to support product realization. Indeed, the scope and intent of ISO 10005 correlates with clause 7.1 quality plans (i.e., product realization plan, i.e., Widget XYZ realization plan, etc.) rather than clause 5.4.2(a) general quality management system planning.

While an ISO 13485 clause 7.1 / ISO 10005 quality plan may indeed address the need for particular quality management system features specific to the object/output of the quality plan, it is nonetheless important that a clause 7.1 quality plan not be confused or equated with clause 5.4.2(a) general quality system planning.

Another way to explain it is that the organization might have multiple clause 7.1 / ISO 10005 quality plans addressing the product realization requirements for various tangible Widgets, projects, or other product realization outputs, whereas clause 5.4.2(a) quality management system planning is a singular (yet ongoing) planning process.

I simply handle ISO 13485:2016 clause 5.4.2(a) by stating in the Quality Manual that:

The organization has determined the processes needed for the quality management system and the application of these processes throughout the organization taking into account the roles undertaken by the organization. [Remember that those roles need to first be specified in an appropriate section of the Quality Manual.]
This also includes planning the sequence and interaction of the QMS processes via the Quality Manual and the documented procedures included or referenced therein.
Moreover, the organization applies a risk-based approach to the control of the appropriate processes needed for the quality management system as described in the corresponding subsection of the Quality Manual (e.g., see ‘Risk-based approach’ under ‘Scope’).
The ultimate output of this planning is the Quality Manual and the procedures included or referenced therein.

Risks from an Inadequate Development Process for Software

Posted by Kevin Randall In Canada, CE Mark, Design & Development, Design Control, EU MDR, FDA QMS, ISO 14971, ISO QMS 0 comment

July 19, 2021

Risks from an Inadequate Development Process for Software

The most fundamental reason for medical device design and development controls (e.g., ISO 13485 clause 7.3; the U.S. FDA’s 21 CFR 820.30, etc.) is to control risks that come from an inadequate development process. That fact is unequivocally true and stands in stark contrast to the erroneous notion that there are no risks from the software development process. For example, in a 6-year study, FDA found that approximately 44 percent of medical device quality problems leading to recalls were attributed to design errors that FDA says may have been prevented by adequate design controls. And regarding design and development of software, FDA did a subsequent study for fiscal year (FY) 1983 through FY 1991 and found that a whopping 90 percent of all software-related device failures were from failure to have a proper software development process.

When approaching risk management regarding the software development process itself (as distinguished from risk management of the software medical device), the general paradigm needs to start from a process-focused approach rather than a device-focused starting point.

There are multiple ways to do process-focused risk analysis. Now, we all know how important it is to realize that FMEA, on its own, is not sufficient to meet ISO 14971’s risk management and analysis requirements. But for temporary discussion purposes, I’m going to dare say something slightly to the contrary in order to help drive home the process-focused concept mentioned above. Specifically, to really grasp the distinction of the process-focused concept, think in terms of p(process) FMEA vs. d(design) FMEA. Okay, there I said it. Now quickly, while my colleagues (and me too of course) are catching their breath and settling down about the mention of FMEA in the context of risk management, I’ll reiterate the disclaimer that we need to be sure and remember FMEA’s intrinsic limitations and intent.

So, if you’re familiar with doing risk analysis for a process (instead of a device), then those principles are the ones that should be applied in order to do risk management of the software development process itself. What can be confusing is that the ultimate purpose of medical device risk management is to control the risks to patients and users. Consequently, it may well be (as the U.S. FDA has indicated), that an inadequate development process can indeed be ultimately correlated to patient and user harms. But there may also be process-centric hazards and harms (derived e.g., via FMEA) that are focused on the process itself. When that is the case, then bridge the ISO 14971 risk management gap by being sure to, where appropriate, ultimately extrapolate (by representation as resulting hazardous situations and sequences of events) into the patient or user harms.

Check out AAMI TIR 36 (Annex B ‘Severity’ explanation under ‘Risk management terminology as it applies to quality and production systems) and ISO 80002-2 (Annex B section B.4) for interesting interpretations of how process risk analysis can differ from product risk analysis. In addition, IEC 60812 also contains some good basic process FMEA insights which can reasonably be adapted for software development process risk analysis.

(Note that it’s only by mere coincidence that AAMI TIR 36 and ISO 80002-2 which I cited happen to involve a software-related context; please note that they aren’t intended to address medical device software validation, nor device software development. Instead, I recommended these resources simply because they coincidentally happen to provide some good illustrations about doing process-focused risk analysis as distinguished from device-focused disk analysis.)

FDA Remote Regulatory Assessment

Posted by Kevin Randall In FDA, FDA Inspections, FDA QMS 0 comment

July 16, 2021

FDA Remote Regulatory Assessment

For the U.S. medical device jurisdiction, a client and I a couple weeks ago went through an FDA Remote Regulatory Assessment (RRA). Here’s a recap:

FDA contacted the firm and informed them that, due to the current SARS-CoV-2 (COVID-19) situation, the FDA is conducting inspections [called Remote Regulatory Assessment (RRA)] on a limited basis at this time. FDA said they were offering the RRAs to firms based on risk, meaning that high-risk firms (e.g., high risk class, poor past inspection results, etc.) would not generally be eligible for the RRA process. FDA proposed a date for conducting the RRA. FDA explained that an RRA is a review of records and information provided by the inspected firm to gain information and to evaluate the firm’s Quality System. The RRA was conducted by a Consumer Safety Officer.

FDA states that the RRA is a voluntary activity that will not result in regulatory action due to non-participation. RRAs may be limited in scope or terminated at the discretion of the Agency. The RRA is limited to reviewing information that can be provided electronically. FDA says that the firm’s ability to do so should factor into its decision for participation.

Refusal to provide information during the RRA is not a refusal under FDA’s inspection authority found in Section 704 of the Act (21 USC 374). Similarly, FDA does not present a Form FDA 482 at the beginning of the RRA, nor does FDA issue a Form FDA 483 at the end even if objectionable conditions are discovered during the RRA. At the conclusion of the RRA, a discussion of findings is held with management officials describing any items FDA wants to bring to the firm’s attention.

Here comes the caveat: Based on the outcome of findings from the RRA, FDA may consider “further communication and/or action”. If significant deficiencies are noted, FDA may begin an onsite regulatory inspection for the purpose of protecting public health. If that’s necessary, then the designated management official will be notified.

We found the RRA to be very informal and pleasant (just short of a trip to the dentist), where information was exchanged merely via telephone, email, and via Zoom online meetings. There was no virtual walk-around of the facility. When all was said and done, three partial days (few hours per day) was spent in the assessment.

Finally, the best news of all: FDA said that the RRA would satisfy the statutory inspectional requirement, thus resetting the firm’s cycle/queue for inspection assignments made via FDA’s inspection scheduling system (e.g., in FACTS).

Send us an email for an example of the information boilerplate that FDA disseminates when it initiates an RRA.

Showing Conformity to Standards

Posted by Kevin Randall In Design & Development, Design Control, FDA, Uncategorized 0 comment

July 16, 2021

Showing Conformity to Standards

Regardless of the source of a request for evidence showing conformity with applicable standards, a pivotal underlying fundamental remains the same and drives the answer: Conformance with standards is generally a design/development verification and/or validation activity. Therefore, the general rule of thumb is that there needs to be a verification and/or validation protocol (explaining, among other things, how the verification/validation will be done), and a report to document the results and conclusions. Stick to the principles embodied for example in ISO 13485 clauses 7.3.6 and 7.3.7 and you should be on track. Failure to do this regarding conformity with applicable standards can lead to compliance (and maybe even safety) problems.

It has been said that design verification may involve inspections, tests, examination, demonstration, or other analyses. And although various verification methods may be employed, any verification approach which establishes conformance with a design input requirement is an acceptable means of verifying the design with respect to that requirement. Sometimes we must get creative for this (e.g., via basic visual inspections, document/content review/confirmations, etc.) when the nature of the verification doesn’t warrant actual testing.

Here are some design validation principles I’ve collected from various resources to help determine what may be appropriate validation techniques for a given scenario: Design validation follows successful verification and may occur in stages. Certain aspects of design validation can be accomplished during the design verification, but design verification is not a substitute for design validation. State targeted user needs / intended uses in objective, measurable terms, including acceptance criteria. Specify the collection of discrete, quantified results that can be objectively measured. Assure that validation studies include actual or simulated use of the product. Specify defined operating conditions (i.e., temperature, humidity, shock and vibration, corrosive atmospheres, etc.) where appropriate. Include statistically meaningful sample sizes that are justified. Validation studies must be performed on initial / pilot production units or their equivalents.

ISO 14971 Estimating Probability of Occurrence of Harm

Posted by Kevin Randall In FDA QMS, ISO 14971, ISO QMS 0 comment

July 13, 2021

ISO 14971 Estimating Probability of Occurrence of Harm

Based on the aforesaid flexibility (see my earlier blog post) allowed by ISO 14971 (e.g., see the third paragraph of ISO/TR 24971 section 5.5.2) for how to estimate probability of occurrence of harm, one might employ a variety of probability expressions. For example, occurrence of harm per day, occurrence of harm per year, occurrence of harm per unit, occurrence of harm per use, occurrence of harm per patient, occurrence of harm per age group, occurrence of harm during the device lifetime, etc.

To help illustrate, here are some hypotheticals:

If a particular harm is estimated to happen once per day with a vital signs monitor model, then the probability would seem to be different (higher) than if that harm is estimated to happen only once per year.

If a particular harm is estimated to happen once per device (e.g., per use, per unit sold, etc.) for a single-use device, then the probability would seem to be different (higher) than if that harm is estimated to happen only 0.001 times per device (e.g., per use, per unit sold, etc.). For example, one occurrence in 100 units sold = 0.01 occurrences/unit sold, whereas one occurrence in 100,000 units sold is only 0.00001 occurrences/unit sold.

Or as another example, 100 occurrences over a ten-year lifetime = 10 occurrences / year, whereas 1 occurrence over a ten-year lifetime is only 0.1 occurrences per year.

Or as a qualitative example: Likely to happen several times during a ten-year device lifetime would be a higher probability than not likely to happen during a ten-year device lifetime (see Table 3 of ISO/TR 24971).

I have seen some who disagree with this logic by asserting that the probability rate doesn’t change based on sales or the size of the installed base, and that the number of devices doesn’t change the rate, and that the rate doesn’t change based on the lifetime of the device). However, I believe such a stance would be at odds with the principles of ISO 14971.

EU MDR Scope and Applicability of GSPR 10.4.1

Posted by Kevin Randall In CE Mark, EU MDR, Uncategorized 0 comment

July 12, 2021

EU MDR Scope and Applicability of GSPR 10.4.1

I think there is a good possibility that GSPR clause 10.4.1’s reference both to “invasive” and to “come into direct contact with the human body” may just be an ambiguous redundancy in describing invasive devices, as I have a hard time imagining an invasive device that doesn’t somehow directly contact the human body. In an explanation from BSI, they seem to have interpreted devices that phrase (“invasive and come into direct contact with the human body”) to simply mean invasive devices.

I’ve also noted that the second two sub-bullets of 10.4.1 are aimed at the indirect contact route (specifically, certain permutations of indirect contact), whereas the first sub-bullet is reserved for the direct contact route (based on its mention of “direct contact” with the human body). Indeed, the European EU MDR authors seem to distinguish between direct contact and indirect contact (as evidenced by the separate dedication to indirect contact in the second two sub-bullets). I would be surprised if the EU MDR authors were lumping indirectly-invasive or indirect-contacting devices into the first sub-bullet; this is because if they were, then it would seem there would be no need for the second two sub-bullets.

Because it seems that CMR and ED substances could reasonably be of concern regarding any device that directly contacts the human body, I’ve been recommending that non-invasive direct contacting device manufacturers go ahead and complete the chemical review just to be safe unless more definitive direction is available for a particular case.

I’m also sensitive to GSPR 23.4(s) which calls for IFU precautions where appropriate related to the presence of CMR and ED substances and the potential for device materials to cause sensitization or allergic reaction by the patient or user. Europe’s liberal stance on toxicants such as CMR and ED doesn’t seem to leave room for excluding users from considerations about the risks of CMR and ED substances. This would seem to further push the GSPR 10.4.1 interpretation toward including non-invasive direct contacting devices.

In any event, I recommend consulting the responsible notified body (if any is involved) to understand its particular interpretation.

1 2 … 5 Next →

Blog

EU MDR PMCF: To Waive or Not to Waive

When is PMCF Required?

The Myth that the EU MDR Doesn’t Allow Waiver of PMCF:

To begin with, be sure not to discount that there is longstanding European historical framework and precedent for waiver of PMCF [see MEDDEV 2.12/2 (for the MDD)]. Indeed, I’ve successfully leveraged such waivers repeatedly with NBs under the MDD without objection.

The option for PMCF waiver is clearly and repeatedly stated by the EU MDR, such as:

Annex II.6.1(d) and Annex III.1.1(b) (applicable to all devices)

Annex IX.2.1 eighth and ninth indents (available as an option for Annex IX devices, which, by the way, could encompass devices all the way up through class III)].

Annex VII.4.5.5 directing Notified Bodies (NB) to make way for PMCF waivers during conformity assessments.

Annex VII.4.6 directing NBs to consider the adequacy of the manufacturer’s PMS plan including a review of the need (or lack thereof) for a PMCF plan.

July 27, 2021

FDA MDUFMA Small Business Determination (SBD) at the Pre-Revenue Stage

Finally, don’t forget that there is a one-time waiver of the MDUFMA PMA fee for a Sponsor’s inaugural PMA pursuant to section 738(d)(1) of the Act.

EU MDR Strategy for Configurable Software

EU MDR Changes to MDD DoC under EU MDR Article 120

ISO 13485 QMS Planning vs. Quality Plans

I simply handle ISO 13485:2016 clause 5.4.2(a) by stating in the Quality Manual that:

This also includes planning the sequence and interaction of the QMS processes via the Quality Manual and the documented procedures included or referenced therein.

Moreover, the organization applies a risk-based approach to the control of the appropriate processes needed for the quality management system as described in the corresponding subsection of the Quality Manual (e.g., see ‘Risk-based approach’ under ‘Scope’).

The ultimate output of this planning is the Quality Manual and the procedures included or referenced therein.

Risks from an Inadequate Development Process for Software

FDA Remote Regulatory Assessment

For the U.S. medical device jurisdiction, a client and I a couple weeks ago went through an FDA Remote Regulatory Assessment (RRA). Here’s a recap:

Finally, the best news of all: FDA said that the RRA would satisfy the statutory inspectional requirement, thus resetting the firm’s cycle/queue for inspection assignments made via FDA’s inspection scheduling system (e.g., in FACTS).

Send us an email for an example of the information boilerplate that FDA disseminates when it initiates an RRA.

Showing Conformity to Standards

ISO 14971 Estimating Probability of Occurrence of Harm

To help illustrate, here are some hypotheticals:

If a particular harm is estimated to happen once per day with a vital signs monitor model, then the probability would seem to be different (higher) than if that harm is estimated to happen only once per year.

Or as another example, 100 occurrences over a ten-year lifetime = 10 occurrences / year, whereas 1 occurrence over a ten-year lifetime is only 0.1 occurrences per year.

Or as a qualitative example: Likely to happen several times during a ten-year device lifetime would be a higher probability than not likely to happen during a ten-year device lifetime (see Table 3 of ISO/TR 24971).

EU MDR Scope and Applicability of GSPR 10.4.1

In any event, I recommend consulting the responsible notified body (if any is involved) to understand its particular interpretation.