Blog

Risks from an Inadequate Development Process for Software

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

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

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

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

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 userEurope’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.

ISO 14971 Probability of Occurrence of Harm

July 12, 2021

ISO 14971 Probability of Occurrence of Harm

 

When tackling the estimation of probability of occurrence of harm during medical device risk management, I think it is important to remember that there is no one-size-fits-all approach.  Instead, each manufacturer’s approach needs to be derived and appropriate based on the nature and complexity of the subject device, as well as on the availability (or lack thereof) of supporting data.

 

The particular approach can either be quantitative or qualitative (see ISO 14971 and ISO/TR 24971).  The probability can be estimated per use, per device, per hour of use, within a population, etc. (ISO/TR 24971).  The particular comparator (i.e., per use, per device, per hour of use, within a population, etc.) needs to be chosen based on the nature of the device.  For example, some devices’ intended use (e.g., reusable devices) will intrinsically make the “per hour of use” comparator more appropriate than per device.  In contrast, single-use devices may very well be appropriate for a “per device” comparator.  The “per device” comparator is where sales numbers may be utilized.  As hinted at above, these are longstanding principles that have been part of the ISO 14971 risk management paradigm for many years.

 

When using a “per device sold” comparator, various factors (e.g., nature and complexity of the device; marketplace tenure, emergent risks or device problems, etc.) will determine whether it is appropriate to use sales per day, per week, per month, per year, cumulative all-time sales, or some other timeframe.  It is up to the manufacturer.  Just be sure that the chosen paradigm makes sense by giving meaningful insight toward the ultimate goal of properly managing the subject device’s risk profile with regard to public health.

 

Consideration of device lifetime when estimating probability of occurrence harm is also a longstanding best-practice in risk management.  Indeed, seeds for this can be found more than two decades back in the year 2000 version of ISO 14971 and even in EN 1441 (1998) that was a gold standard before modern risk management really got traction via the ISO 14971 series.  Moreover, the consideration of device lifetime as part of estimating probability of occurrence harm remains a modern best practice today in the latest versions (see ISO 14971:2019 and ISO/TR 24971:2020), for example where it’s stated that device lifetime is an important factor for estimating probability of occurrence of harm.  Accordingly, it is wise to figure out what is meant by device “lifetime” in the context of risk management and for the estimation of probability of occurrence of harm.

 

On that note, my experience has been that there seems to be harmonized general agreement on the meaning of device “lifetime”.  That said, I haven’t found many standardized, statutory, or legislative definitions for this.  At the moment, I generally rely on, adapt, and/or expand existing explanations such as:

 

 

  • FDA’s 21 CFR Part 803.3: “…(f) Expected life of a device means the time that a device is expected to remain functional after it is placed into use. Certain implanted devices have specified “end of life” (EOL) dates. Other devices are not labeled as to their respective EOL, but are expected to remain operational through activities such as maintenance, repairs, or upgrades, for an estimated period of time…”

  • ISO/TR 24971:2020: “…What determines the lifetime of the medical device?…Factors that should be considered include battery depletion, deterioration of materials and failure of components due to ageing, wear, fatigue or repeated use. The availability of spare parts should be considered as well…” [emphasis added].

  • FDA’s 2016 3rd Party Servicing Workshop: “…Information about reliability is needed to…understand the expected life of the device…” [emphasis added].

  • ISO TC/210: “…the rationale for the determination [of medical device lifetime] should be recorded and can involve consideration of the following…shelf life of the medical device…expiry date for medical devices or components which are subject to degradation over time…number of cycles or periods of use of the medical device, based on life testing of the medical device…anticipated material degradation…stability of packaging material…for implantable devices, the residual risk that results from the entire period of residence of the medical device inside the patient’s body…for sterile medical devices, the ability to maintain sterility… organization’s ability/willingness or contractual or regulatory obligation…” [emphasis added].

 

 

 

EU MDR CE Marking On Advertising Materials

July 9, 2021

EU MDR CE Marking On Advertising Materials

 

Though many of us have undoubtedly observed the placement of a CE mark on promotional flyers, I suggest that such a practice is contrary to the basic product-inscription intentions established by the European authorities for use of the CE mark.  Accordingly, I recommend against placing CE marks on advertising literature, websites, and other promotional pieces, except for “sales packaging” (i.e., artwork on physical boxes, pouches, etc.).  I explain further below.

 

When reviewing the basic principles for CE marking in EU MDR Article 20 and Annex V, in the Blue Guide, in Europe’s “common framework” for marketing of products, in Regulation (EC) 765/2008, and the like, the intrinsic focus is oriented toward the subject device’s physical, chemical, configurational, functional, etc., attributes, and the ability of those attributes to support the affixing of the CE mark inscription.  We know this to be true because key legislative concerns are visibility, indelibility, readability, dimensional, etc., with immediate provisions for alternative marking options regarding devices whose basic physical, chemical, configurational, functional “markability” (my own term) don’t permit the affixing of the CE mark to the device, where in such instances we can instead place the mark on the accompanying legislatively-driven documents (i.e., on the information supplied with device, i.e., on the EU MDR Annex 1 Section 23 information, i.e., on the label and instructions for use).

 

Another telling angle is the Blue Guide’s statement that “CE marking does not serve commercial purposes, i.e. it is not a marketing tool.”  Accordingly, I suggest that the EU MDR Article 20(5) reference to, “promotional material which mentions that a device fulfils the requirements for CE marking” [my emphasis added] should be interpreted as just that [i.e., as a “mention of”, i.e., as a promotion of, the device’s conformity), rather than to the actual affixing of a CE mark to the promotional materials.

 

Health Canada Medical Device Importer Requirements for DTC Sales

July 7, 2021

Health Canada Medical Device Importer Requirements for DTC Sales

 

When dealing with Health Canada’s medical device regulatory requirements (i.e., SOR/98-282 as amended from time to time, hereinafter the “CMDR”), there are four device classes: I, II, III, and IV.  Therefore, when adapting a regulatory strategy from surrounding jurisdictions, be sure to consider the unique differences in Canada’s device classification scheme, such as with respect to the EU’s class IIa category, or such as with respect to the USA, which only has three risk classes.

 

The CMDR don’t demand that an importer be designated for each imported shipment or device.  Rather, it has been my experience that a person automatically becomes an importer based on whether the person engages in activities that meet Health Canada’s definition for importer.  Oddly enough, neither the CMDR nor its statutory counterpart (the Canadian Food and Drugs Act) define importer.  But in guidance (see GUI-0016), ‘importer’ is defined as a person in Canada, other than the manufacturer of a medical device, who is responsible for the medical device being brought into Canada for sale.

 

In the case of internet sales directly to consumers for personal home use, Health Canada has expressed to me in prior correspondence that such a consumer is viewed to be the importer.  However, for that type of importer, neither the importer MDEL requirements (nor any other CMDR importer requirements) apply because of CMDR subsection 2(b).  For example, GUI-0016 states an MDEL exemption for “any person who imports a medical device for his/her own personal use”.

 

EU MDR Applicability for Changes to Pre-26 May 2021 Devices

July 7, 2021

EU MDR Applicability for Changes to Pre-26 May 2021 Devices

 

Remember (see my post from yesterday) that EU MDR requirements (like EU MDR vigilance procedures, EU MDR corrective action reporting, etc.) generally doesn’t apply for changes involving device units that were legally placed on the market and put into service in the Union prior to 26 May 2021 unless a significant change is made that renders the devices to be “new” devices.  In other words for example, if the change to such pre-26 May 2021 devices are part of a FSCA, then the FSCA requirements of the MDD apply, not the EU MDR.

Particular EU MDR requirements will only become applicable regarding changes to devices placed on the market, made available on the market, or put into service in the Union from 26 May 2021 [notwithstanding the provision of Article 120(5) of course] or regarding significant changes to pre-26 May 2021 units.

Therefore, be careful not to unnecessarily/improperly apply EU MDR requirements to devices legally placed on the market or put into service before 26 May 2021 [except regarding Article 120(5)].

 

EU MDR & MDD Redundant Certification

July 6, 2021

EU MDR & MDD Redundant Certification

 

An MDD-certified device is generally eligible for participation in the EU MDR Article 120(2) and/or (3) 2024 transitional buffer.

 

 

An MDD-certified device is generally eligible for participation in the EU MDR Article 120(2) and/or (3) 2024 transitional buffer.  In that case, the MDD DoC can remain in effect (pursuant to certain EU MDR limitations) until replaced and/or supplemented by an EU MDR certificate and DoC.  But once EU MDR conformity is achieved, then I know of no legislative reason to thereafter redundantly maintain the MDD certificate, though I suppose there could be business reasons for such redundancy.  For the latter, it would mean a) that the manufacturer is willing to pay the NB(s) for the additional/duplicative conformity assessment services; and b) if the same NB will be used for both certifications, then such NB i) has the bandwidth and willingness to support such redundancy; and ii) such dual certification doesn’t violate the impartiality clauses (such as those in 4.2.4 regarding self-interest and familiarity) of the ISO 17021 standard(s) governing the NB.  Other than that, I can’t bring to mind other reasons that would prohibit such dual certification by a single NB.  But be sure to consult the NB involved so as to determine its particular stance on the matter.

 

Regarding significant changes to an existing MDD-compliant install base, refer to my related blog posts here and here.