Blog

Use of Off-Label Clinical Data in Premarket Submissions

April 13, 2023

Use of Off-Label Clinical Data in Premarket Submissions

 

 

The supporting clinical data for a U.S. 510(k) notification (or other U.S. premarket submission) must generally meet FDA’s standard for “valid scientific evidence”.  Specifically, that means (21 CFR 860.7) evidence from well-controlled investigations, partially controlled studies, studies and objective trials without matched controls, well-documented case histories conducted by qualified experts, and reports of significant human experience with a marketed device, from which it can fairly and responsibly be concluded by qualified experts that there is reasonable assurance of the safety and effectiveness of a device under its conditions of use. The evidence required may vary according to the characteristics of the device, its conditions of use, the existence and adequacy of warnings and other restrictions, and the extent of experience with its use.  However, isolated case reports, random experience, reports lacking sufficient details to permit scientific evaluation, and unsubstantiated opinions are not regarded as valid scientific evidence to show safety or effectiveness.

 

These provisions would need to be carefully considered when assessing the utility of off-label clinical data/experience for the purposes of supporting eventual market authorization.

 

In terms of soliciting additional off-label experience/data, that gets to be a tricky scenario.  Specifically, FDA has strongly established that it can, and has, considered off-label use to actually become intended use once the manufacturer’s corresponding awareness reaches a certain level.  So this can get us in hot water quick once there is a known intended use for which no premarket authorization has yet been obtained.

 

The regulations require us to instead solicit/sponsor/facilitate such off-label use only under proper clinical investigation controls (see 21 CFR Part 812) and/or to assure that retrospective and unsponsored clinical data were gathered under comparable clinical investigation controls or equivalent (e.g., for overseas studies/data, compliance with the Declaration of Helsinki, ISO 14155 as amended and with any regional versions, etc.).

UDI for IVD Devices Used In-House: Part 2

April 13, 2023

UDI for IVD Devices Used In-House: Part 2

 

Once the reagent kit components (i.e., essential parts of the finished IVD device) of an IVD are sent to the healthcare facility for clinical use, then the finished IVD is in commercial distribution (thus triggering the UDI requirements) as I understand it.  Also, the UDI requirements are generally aimed at finished devices rather than components or shipping containers. So the UDI regulations don’t generally provide for parsing the finished device up into pieces for the purposes of UDI.

 

Moreover, in light of the key intent of the UDI traceability requirements, the healthcare facility still has a critical interest in the proper functioning of the manufacturer’s in-house assay/test.  For example, in the event of false positives/negatives that adversely affect clinical decision making/treatment, then the fundamental intent of the UDI requirements is that all parties, including the healthcare facility, be able to link the issue back to the suspect assay/test.  Lack of assay/test UDI could prevent this fundamental intent from being met, and thus in the eyes of the UDI regulations, would represent insufficient protection of public health.

 

Another aspect is that if the IVD’s cleared/approved labeling, premarket authorization data [e.g., in the 510(k), PMA, EU Technical Documentation, etc.] don’t clearly restrict the assay/test to use only at the IVD manufacturer’s in-house lab (e.g., if they don’t contraindicate against use outside the manufacturer’s in-house test environment), then that also works against the notion of a UDI exemption, as such premarket authorization is contingent on UDI compliance.

 

Accordingly, my understanding is that the UDI requirements definitely still apply to a finished device IVD consisting of the assay/test and its reagents. If one’s strategy was to try and exempt part(s) of the commercialized finished device from the UDI requirements, then that could definitely translate to compliance risk, public health risk, and legal/liability risk.  I would at least look to assure agency authorization for such an approach before implementing it.

UDI for IVD Devices Used In-House: Part 1

April 12, 2023

UDI for IVD Devices Used In-House: Part 1

 

The U.S. FDA’s and the IVDR’s requirements for UDI aren’t generally contingent on where the subject device is used.  Instead, the requirements are contingent on the definition of “medical device” and “in vitro diagnostic medical device” (hereinafter “device” / “devices”).  Specifically and plainly, the manufacturer is generally required to assign and maintain unique UDIs for its devices.  A driver for this is the basic intent of the UDI requirements, which is to facilitate device traceability.  The basic need for device traceability is important whether the device is used in-house or out in the field.  Accordingly, regulators would likely push back against the assertion that UDI traceability isn’t value added.  I would steer clear of trying to argue against that.

Design Plans: Clearly Identify Design Team Members/Contributors

April 11, 2023

Design Plans: Clearly Identify Design Team Members/Contributors

 

It’s important to be mindful that ISO TC/210 and FDA expect the design team and its members’ roles to be very clearly defined (i.e., in the design plan).  FDA says that, “The importance of defining responsibilities with clarity and without ambiguity should be recognized.”  ISO TC/210 says, “It needs to be clear who has responsibility and authority for design and development. Generally, as different groups or functions within your organization are involved in design and development, clear and effective communication with distinct assignment of responsibilities across your organization is important….The design and development plan should identify the review, verification and validation methods to be used, including who is to carry them out…” [emphasis added].  This alludes to the pitfalls of arguing against a regulatory authority who seeks inclusion of the various personnel contributions as being part of the design team.

FDA ESG Digital Certificates

April 10, 2023

FDA ESG Digital Certificates

 

If you are having trouble getting FDA’s ESG portal to work for you because of rejected digital certificates, then there there are at least a couple of alternatives.  Specifically, you can seek expert third party assistance getting your digital certificate issues resolved; and/or in the meantime while your digital certificate issues are being resolved, you can have a third party submit the eMDRs on your behalf using the third party’s ESG account.  That is a service that ComplianceAcuity can offer.

 

During times of complete desperation, a less viable temporary option is to, as an interim measure, submit the MDR directly to FDA’s MDR Team with an explanation that you haven’t yet been able to get your ESG submissions to work.  Be aware that FDA will reject such a submission method and you will eventually still need to submit the eMDR via the ESG. But you will at least have shown in good faith your intent to inform the agency of the reportable adverse event.

 

And here are some pointers for getting your FDA ESG digital certificates to work:

 

  • The digital certificates authenticate the sender (kind of like a digital signature would).

  • The sender must have two certificates: a “Public Key” certificate (file type .cer) and a “Private Key” certificate (file type .pfx).

  • Together, these seem to meet the X.509 specification requirement.

  • These certificates expire and will need to be renewed on a periodic basis.

  • Keep your certificate files accessible at a known location on your computer.

  • To see if they are not expired, click on the .cer file and a window will pop up with certificate details.

  • If expired, then you will need to obtain new certificates.

  • Once obtained, export the Public Key and Private Key (the .cer and .pfx files) (see https://www.fda.gov/industry/about-esg/esg-appendix-c-digital-certificates).

  • Install them.

  • Update the Public Key (the .cer file) needs to be uploaded into your User Portal at https://esgportal.fda.gov/.

  • Once that upload is completed, then submissions should be accepted via your ESG production account.

  • Note that when making an actual ESG submission, the .pfx certificate file is the one that is linked/uploaded as part of the ESG submission, not the .cer certificate file, so be sure your linking the correct one, or the ESG submission will fail.

EU MDR Basic UDI-DI “essential design and manufacturing characteristics”

April 7, 2023

EU MDR Basic UDI-DI “essential design and manufacturing characteristics”

 

According to the MDCG (2018-1), the Basic UDI-DI is the main key in the database and relevant documentation (e.g. certificates, declaration of conformity, technical documentation and summary of safety and clinical performance) to connect devices with same intended purpose, risk class and essential design and manufacturing characteristics.  While this definition is a departure from the official definition in the EU MDR and IVDR, the Commission appears to have endorsed it nonetheless when the Commission used that definition in its 01/08/2020 ‘What you need to know!’ / FAQ document on UDI. I’ve also see notified bodies like BSI endorse the MDCG definition.

 

Since for this context the EU MDR and IVDR don’t actually define what is meant by “essential design and manufacturing characteristics“, we seem to be left with some liberty in how to interpret that phrase when approaching the Basic UDI-DI.  This becomes particularly important when grappling with whether a device change requires a new Basic UDI-DI.

 

ComplianceAcuity’s recommended approach is to assess the impact of a change on the Annex II Section 3 technical documentation (Design and Manufacturing Information).  If a device or manufacturing change is made that significantly affects that Section, then there is a good chance that a new Basic UDI-DI is needed.  I would also go further and say that if there is a significant impact on the conformity information used for Annex II Section 4 (General Safety and Performance Requirements) (e.g., in the GSPR checklist) with regard to the GSPR(s) related to device design and manufacturing, then that would also be an indication of an impact on the Basic UDI-DI.

Health Canada Medical Device System License Components Sold Separately

April, 6, 2023

Health Canada Medical Device System License Components Sold Separately

 

In general, components of a licensed medical device system can be sold separate from the system on the condition that the label of each component bears the system name. Also, strictly speaking based on Health Canada’s CMDR and guidance terminology and interpretations, additional conditions are that, to be covered by the Medical Device System license, here are some important rules regarding the System’s components:

 

  • “Component” means one of several possibly unequal subdivisions into which something is or is regarded as divided and which together constitute the whole. A component may also be referred to as a part or an accessory.

 

  • Components not sold under the System name cannot be licensed with the System, even when they are intended to be used together.

 

  • All the Components of a System must be listed on the license application by Medical Device Name and by Identifiers (e.g., Catalog Number, etc.).  This means they must also appear on the System license via those identifiers.

 

  • The application must provide documentation and information on all Components of the System.

 

But if one were aiming to deviate from these strict interpretations (for example by claiming that a subcomponent is just a replacement/consumable part), then it would be best to first consult Health Canada for permission regarding such deviations. Otherwise, such subcomponents will need their own dedicated Device License(s), either by way of amending the current System license to add the additional descriptors, or else by getting a new individual device license(s) depending on further details of the scenario.

Is that eQMS platform (such as SharePoint) fit for its purpose?

April 6, 2023

Is that eQMS platform (such as SharePoint) fit for its purpose?

 

I saw a question today wondering whether SharePoint is suitable for maintaining a medical device QMS documents system and record control. In a nutshell, SharePoint (or whatever other eQMS practice is proposed) may or may not be suitable for maintaining the QMS documents system and record control, or for other QMS operations, depending on the case.  Here are some key points to consider when figuring out whether a computer platform is suitable for QMS purposes:

 

  • ISO 13485:2016 (as amended; hereinafter “ISO 13485”) is intended (clause 0.1) to allow flexibility, rather than mandated uniformity, in the structure of different quality management systems.  Accordingly, ISO 13485 doesn’t out right prohibit the use of SharePoint, nor any other eQMS solution, to facilitate QMS operations.

 

  • ISO 13485 doesn’t really allow anyone to just “believe” that an eQMS approach is unfit.  Instead, we are expected to employ an impartial scientific method whereby we validate the software for its defined intended use per clause 7.5.6, fourth paragraph.  If the software fails that process, only then can we conclude it is unfit for its purpose.  Don’t be tempted to assert unfitness apart from that impartial scientific method.

 

  • The U.S. FDA’s eQMS software validation requirements [21 CFR §820.70(i)] reflect the same principles as described above for ISO 13485.

Don’t confuse FDA’s Part 11 with FDA’s software validation requirements of §820.70(i)

April 6, 2023

Don’t confuse FDA’s Part 11 with FDA’s software validation requirements of §820.70(i)

 

I oftentimes see narratives that state or imply that FDA’s security and integrity requirements for electronic records and signatures from 21 CFR Part 11 are the same thing as FDA’s quality system or manufacturing “software validation” requirements in 21 CFR §820.70(i) .  But these two things, though related, aren’t the same.  Specifically,

 

  • 21 CFR 820.70(i) requires (among a couple other things) that, whenever computers or automated data processing systems are used as part of the QMS, then the manufacturer shall validate computer software for its intended use according to an established protocol.  This is FDA’s primary medical device QMS software validation regulation. As an aside, it is generally understood in the software validation community that the OQ/PQ concepts from the process validation world aren’t proper fits regarding software validation.  This is because the OQ/PQ concepts, when deployed as intended, are focused on process development and repetition which aren’t generally germane for software validation.  Indeed, if a software validation protocol employs the OQ/PQ concepts, then it’s most likely that it isn’t actually real OQ/PQ that is being done.

 

  • Regarding 21 CFR Part 11, it’s important to remember and distinguish that its fundamental purpose is limited to, and focused on, when required records and signatures are kept in electronic format.  If so, then it demands the security and integrity controls of 21 CFR Part 11.  But two important points there:

 

    1. Don’t holistically equate Part 11’s coincidental validation requirements with the overarching software validation requirements of 820.70(i); and

    2. Remember in any event that FDA is currently employing Part 11 enforcement discretion as follows:

      1. fewer records are subject to Part 11 (FDA is only applying Part 11 if the required records or signatures are kept in electronic format instead of paper, or if one other similar condition is met);

      2. For those records that remain subject to Part 11, FDA is exercising enforcement discretion with regard to Part 11’s requirements for validation, audit trails, record retention, and record copying, yet while Part 11’s other requirements (e.g., limiting system access, use of various checks, etc.) continue to apply.

eIFU MDD & EU MDR Notified Body is Required (as applicable)

April 6, 2023

eIFU MDD & EU MDR Notified Body is Required (as applicable)

 

Both Regulation (EU) 207/2012 (the eIFU regulation for the MDD) and Regulation (EU) 2021/2226 (the eIFU regulation for the EU MDR) require that conformity with those regulations be reviewed by a European notified body where applicable (i.e., for those device classes/types requiring notified body involvement for conformity assessment).