Audit Core Matrix – Device CGMPs Documentation Review:  Systems, SOPs, records, et al, (references are to 21 CFR Part 820, Quality System Regulation:

 

Subpart                Description                                                     Reviewed (‘Y’ or ‘N’) / Comments

 

  A                           General (820.1, -.3, -.5)  

  B                           Quality System Requirements    (820.20, 

                                -.22, -.25)

  C                           Design Controls (820.30)                

  D                           Document Controls (820.40)       

  E                           Purchasing Controls (820.50)      

  F                           ID and Traceability (820.60,  -.65) 

  G                          P and PC (820.70, -.72, -.75)                                                        

  H                          Acceptance (820.80, -.86)              

  I                           Nonconforming Product (820.90) 

  J                           CAPA (820.100) 

  K                          Labeling and Packaging Control (820.120

                               -.130)                

  L                          Handling, … (820.140, -.150, .160-.170)                                                         

  M                         Records (820.180, -.181, -.184, -.186, -.198)                                                         

  N                          Servicing (820.200) 

  O                          Statistical (820.250)

-- jel@jelincoln.com

The Virtual / Remote Compliance Audit

The following three posts address an approach to virtual / remote internal or vendor audits;  starting with the final report, then the conduct of the Audit, then back to the Audit Plan.  Use a video conferencing app, solicit key documents in e-form prior to audit.  Then follow the Audit Plan with a discussion of each element with the team, requesting any supporting documentation in e-format, or similar, camera pix, or similar.  

Remote / Virtual Audits - Internal or Vendor Audits -  The Final Audit Report

 

ISO 13485  COMPLIANCE  AUDIT  REPORT

 

 

 

CONFIDENTIAL

 

 

 

 

Prepared For: 

 

         

                                                          

                                                          

 

 

 

 

Site Audited (Remote / Virtual):

 

     

 

 

                                                          

                                                                       

 

 

___________________________________________________________________________

 

J.E.LINCOLN and Associates LLC                                                                                phone     435-840-0252

P O Box 2786                                                                                                                       

St George  UT  84771-2876                                                                                            www.jelincoln.com                                                                                                                                                   e-mail     jel@jelincoln.com

 

 

 [page break]

 

COMPLIANCE AUDIT REPORT  

 

CONFIDENTIAL

 

SITE:                                                   

 

AREA(S) AUDITED:

 

AUDIT TEAM:           John E. Lincoln

 

DATE(S) OF AUDIT:

 

DATE OF REPORT: 

 

PERSON(S)

         CONTACTED:  

 

[page break]

 

01.  INTRODUCTION:  [Background, scope, team, process, timing, approach …]

 

 

 

03.  MAJOR  FINDINGS  AND  OBSERVATIONS:

 

[Completed Matrix findings and expamded discussions of findings]  

 

04.  RECOMMENDATIONS:

 

Signed:                                     

 

Printed Name: John E. Lincoln

 

Date:               

 

 

-- END OF  AUDIT  REPORT BODY –

 

 

 

Attachments:                 1 – ISO 13485:2016, Filled-In Audit Matrix

                                       2 – Current Company SOP Listing.

                                       3 – Audit Plan

4 – Audit Flow Chart

-- jel@jelincoln.com

 

Remote / Virtual Audits - Internal or Vendor Audits -  The Audit

Conduct per the Audit Plan, adjusted by any client / team feedback.

The Audit CGMP Sub-clause Matrix (ISO 13485 or 21 CFR 211, or 820, etc):

 

EU ISO 13485:2016  COMPLIANCE  AUDIT  MATRIX

 The following are ISO 13485:2016, Quality Management Systems for Medical Devices clauses (may be used as an audit checklist):

Clause                   Description                                            Reviewed (‘Y’ or ‘N’) / Comments

 

   4                        Quality Management System

                              4.1  General requirements

                              4.2  Documentation Requirements

                                              4.2.1  General

                                              4.2.2  Quality manual

                                              4.2.3  Medical device file

                                              4.2.4  Control of documents

                                              4.2.5  Control of records                                         

                            

 

    5                         Management Responsibility

                                5.1  Management commitment

5.2  Customer focus

5.3  Quality policy

5.4  Planning

                5.4.1  Quality objectives

                5.4.2  QMS planning

5.5  Responsibility, authority and communication

                5.5.1  Responsibility and authority

                5.5.2  Management responsibility

                5.5.3  Internal communication

5.6  Management review

                5.6.1  General

                5.6.2  Review input

                5.6.3  Review output

 

6              Resource Management

                6.1  Provision of resources

                6.2  Human resources

                6.3  Infrastructure

                6.4  Work environment and contamination 

                       control

                                6.4.1  Work environment

                                6.4.2  Contamination control

 

7              Product Realization

                7.1  Planning of product realization

                7.2  Customer-related processes

                                7.2.1  Determination of requirements 

                                           related to product

                                7.2.2  Review of requirements related 

                                           to product

                                7.2.3  Customer communication

 

Page 2 

Subpart                 Description                                                 Reviewed (‘Y’ or ‘N’) / Comments

 

 

                7.3  Design and development

                                7.3.1  General

                                7.3.2  Design and development planning

                                7.3.3 Design and development inputs

                                7.3.4  Design and development outputs

                                7.3.5  Design and development review

                                7.3.6  Design and development verification

                                7.3.7  Design and development validation

                                7.3.8  Design and development transfer

                                7.3.9  Control of design and development 

                                          changes

                                7.3.10 Design and development files

                7.4  Purchasing

                                7.4.1  Purchasing process

                                7.4.2  Purchasing information

                                7.4.3  Verification of purchased product

                7.5  Production and service provision

                                7.5.1  Control of production and service

                                          provision

                                7.5.2  Cleanliness of product

                                7.5.3  Installation activities

                                7.5.4  Servicing activities

                                7.5.5  Particular requirements for 

                                          sterile medical devices

                                7.5.6  Validation of processes for 

                                           production / Service provision

7.5.7  Particular requirements for validation 

          of processes for sterilization and 

          sterile barrier systems

7.5.8  Identification

7.5.9  Traceability

                7.5.9.1  General

                7.5.9.2  Particular requirement for 

                              implantable medical 

                              devices

7.5.10 Customer property

7.5.11 Preservation of product

7.6  Control of monitoring and measuring 

       devices

8              Measurement, Analysis and Improvement

                8.1  General

                8.2  Monitoring and Measurement

                                8.2.1  Feedback

                                8.2.2  Complaint handling

                                8.2.3  Reporting to regulatory 

                                          authorities

                                8.2.4  Internal audit

                                8.2.5  Monitoring and measurement 

                                          of processes

                                8.2.6  Monitoring and measurement 

                                          of product

                8.3  Control of nonconforming product

                                8.3.1  General

                                8.3.2  Actions in response to

                                          non-conforming product

                                         detected after delivery

                8.4  Analysis of data

                8.5  Improvement

                                8.5.1  General

                                8.5.2  Corrective action

                                8.5.3  Preventive action     

                      

                                                                                                #  #  #

 -- jel@jelincoln.com

Remote / Virtual Audits - Internal or Vendor Audits - Audit Plan

Audit Plan (published in advance of audit; for a one day audit' smaller company):

AUDIT PLAN

I plan for a basic one day remote / virtual ISO 13485 compliance audit to follow the ISO 13485:2016 International Quality Management Standard for Medical Devices, per your request.

Preliminary Schedule:

[Note:  If any of the following can be segregated or collected prior, it would facilitate the thoroughness of the audit].   Times are approximate.

Since this is a remote / virtual audit, much information will be by question and answer, e-copies and/or PDF’s of some documents, and possibly live camera shots of some areas, documents, etc.

8:00  AM         Approximate arrival by Zoom. 

8:05  AM         Meet with Company / Quality Management Team:

                        o  Review Audit Plan; make any desired changes in focus / emphasis

                        o  Review corporate history, relationship, management/Org Chart(s),                                      product line, registrations / certifications, marketing ads /claims.

8:30 AM        “Tour” of facility, review of physical activities, gathering of any forms,                     supporting documentation not previously obtained, develop rough                        flow chart -- preferably in the following order:

                        1. ‘Back office’/support staff activities (purchasing, customer service);

                        2.  Raw material, parts components receipt/  QC;

                        3.  Manufacturing/assembly/processing, test / QC, operations;

                        4.  Product shipment / QA;

                        5.  R&D;

6.  Engineering;

7.  QA/RA;

8.  Senior Management and documented involvement in QMS.

9:30 AM          Review all applicable ISO 13485 requirements per Check List.

10:30 AM       Detailed review of company QMS-related SOPs / written documentation    

and/or forms, Work Instructions, Quality Manual (SOPs and QM previously provided), e.g.:

                        1.  Purchasing/POs;

                        2.  Receiving documentation, Invoice verification/control;

                        3.  Inventory, non-conformance (rejects, damaged parts/product...) control;

                        4.  Product assembly, test procedures and/or work instructions;

                        5.  Packaging, shipping, servicing, returns...);

                        6.  Validation Reports;

                        7.  Design and Development Planning / Files;

                        8.  Device Risk Management Files, ISO 14971:2019;

                        9.  Use Engineering Files, IEC 62366-1:2015, if applicable;

                        10.  Other Audits (Internal, Vendor, Regulatory…);

All applicable activities addressed by SOP, WI, and followed, proved by documentation. 

12:00 Noon     Lunch Break (start draft report)

1:00  PM        Review any outstanding issues

 1:45  PM        Dismiss team;  Start drafting the Audit Report / Regulation Sub-Clause Matrix 

4:30  PM       Close-out meeting with QMS team/senior management (as available).

 5:00 PM        Conclusion.    

 Note:  Sequences approximate, based on areas requiring in depth review; but audit content will basically follow outline above.  In order to better benefit from this audit, the company’s QMS Team should review ISO 13485:2016 and our supplied Check List and Plan to get a flavor of the audit’s areas of emphasis.

After the Draft’s findings have been agreed to, a Corrective Action Plan will be drafted.

Assistance in Corrective Action is not part of this Plan.

The Final / Formal Audit Report will be mailed in approximately two weeks following audit’s conclusion. 

-- jel@jelincoln.com

DHF, Risk Management, Use Engineering

One of the participant who attended the 6-Hour Virtual Seminar on The DHF, DMR, DHR, EU MDR Technical Documentation Similarities, Differences and The Future asked:

I would like to ask what I need to do for legacy medical devices (FDA Class 2).

My company has 510(K) clearance back in 2000. Since most of the requirements happened post 2000, may I know what I should for the legacy medical device related to:

• DHF (should I remediate it?) – some of the info may not be available (i.e., design review/meeting minutes/decision, formal approval (no proper documents control before), other validation records)
• ANS:  Where the DHF was complete in 2000 . it does not need remediation.  Areas of incompleteness can be added by researching old documentation, interviews, lab books, etc.  and added (not backdated) to the DHF with explanation. Known missing data can also be stated and a document / memo to file added (actually or as an addendum).  Subsequent changes are addressed in the DHF if your company keeps it open / controlled, but as I mentioned in the webinar, I don't recommend that.  I recommend changes controlled by 1) a new DHF if extensive, 2) an addendum to the old DHF if extensive, or 3) use the CGMP Change Order system, 820.40(b).  In all cases, a change, single or cumulative, must be evaluated / documented, as to the need to file a new 510(k). Remember to view the DHF through both regulatory and IP (intellectual property) "eyes".

• Risk Management (RM) – DHF has been closed and now tracked under DMR – do I need to go back to update RM (per latest standard) during design stage which has been closed? Or update incremental to the latest standards? Or it’s OK to meet RM requirements at the time of design stage & no further work required (perhaps only periodical review post-market)?
• ANS:  Although RM should be done as part of the Design (Design Control, 820.30, ISO 13485  7.3) process. since RM drives all device decisions throughout its lifecycle, the RM File must be a living / controlled document, updated as new applicable information becomes available (through CAPA, V&V, industry data, annual quality review, etc.). That's why I recommend in the webinar that the RM File and Use Eng'g File (if any) have a non-controlled copy in the DHF (or a pointer to it/ them), of the version used during the design phase, prior to Design Transfer , and the actual RM (UE) Files be active and controlled (change controlled). The new version of ISO 14971 adds the need to add systemic RM considerations to the QMS.  Any change in emphasis re: Device (not QMS) RM based on the new 14971 rev could be addressed during one of those reviews / file updates. 

• IEC62366 – As it comes after 2000 which was not done before during 510(K) approval, do I still need to do it if no major changes to medical devices which have been shipped to market for ~20 years? I come across User Interface of Unknown Provenance (UOUP), what’s the minimum efforts that I need to take?
• ANS:  You as a company need to decide based on novelty of your device and any user interface concerns that are still applicable 20 years later.  Human factors was a concern with the FDA in 2000, when they starting publishing documents on it.  If your product / family has minimal field problems due to design / interface issues, I personally haven't seen regulatory agencies raise an issue about it.
  
• ANS:  If the use interface falls under UOUP, you should consider all 9 stages of 62366-1, and revisit those that don't appear to be addressed, and/or pose a high risk to the end user / patient; and document this evaluation - basically a Gap analysis. Some devices are so obvious as to use (or are subject ot med school et al training) that a UE analysis may not be justified, e.g., standard needles. Address in your applicable SOPs, and by a written rationale / letter to file.

--  jel@jelincoln.com

FDA's "Backup" in Data Integrity

 Data integrity  Backup:

"How does FDA use the term “backup” in § 211.68(b)? 

FDA uses the term backup in § 211.68(b) to refer to a true copy of the original record that is maintained securely throughout the record retention period (e.g., § 211.180). Backup data must be exact, complete, and secure from alteration, inadvertent erasures, or loss (§ 211.68(b)). The backup file should contain the data (which includes associated metadata) and should be in the original format or in a format compatible with the original format. FDA’s use of the term backup is consistent with the term archive as used in guidance for industry and FDA staff General Principles of Software Validation. 

Temporary backup copies (e.g., in case of a computer crash or other interruption) would not satisfy the requirement in § 211.68(b) to maintain a backup file of data."

--https://www.fda.gov/media/119267/download   page 5

The key difference appears to be the accuracy, integrity, exact nature of the data, consistent  with the meaning of archived, and PERMANENT.  As opposed to temporary backup files kept for a period of time for reference and then overwritten, which don't meet the FDA definition of "backup" in the sense of data integrity.  

-- jel@jelincoln.com

Remember, any electronic files retained as "backup", or for any other CGMP compliance reason, must be readable througout the lifetime of the record.  This means that as technology changes electronic storage media, we must either keep obsolete readers in operating condition, or migrate our archived electronic records (and readers) over to the new media / readers, in harmony with CGMP requirements for the accuracy and verifiability / validatability of such a migration.  - JEL  02/06/2023  

Is the UKCA logo similar to the EU CE Mark?

 In response to a question from one of the attendees of a recent 6 hour webinar on "The DHF, DMR, DHR, Technical Documentation - Similiarities, Differences and The Future":

Ques: Is the UKCA logo similar to the CE-2 logo:

Ans: No, not if I understand your question.  UKCA (United Kingdom Conformity Assessed) has it's own version of the CE-Mark, the UKCA (Google to see appearance). This question is tied to the larger question of how the UK is adjusting to it's own versions of the EU's CE-Marking, EU's MDR, etc.

Note the following from the UK:

https://www.gov.uk/guidance/using-the-ukca-marking

also note this item:

From 1 January 2021 the technical requirements (‘essential requirements’) you must meet – and the conformity assessment processes and standards that can be used to demonstrate conformity – will be largely the same as they are now… the UK standards will be the same in substance and with the same reference as the standards used in the EU. However, they will use the prefix ‘BS’ to indicate that they are standards adopted by the British Standards Institution as the UK’s national standards body” -  gov.uk website

"Essential requirements" are their words, not sure if they mean that generically or not, since the EU MDR now uses "General Safety and Performance Requirements" i(EU MDR) n lieu of  "Essential Requirements"  (old EU MDD), as I explained in the webinar. 

There is also a 2 year transition period, from Jan 01, 2021 - Jan 01, 2023, in many applications.  And N. Ireland is exempt from most of Brexit, and adheres to the EU in general, while Wales and Scotland are also associated with Brexit.

Please check with your notified body for the specifics of requirements and implementation of Brexit's adjustment to pulling out of the EU, the MDR and CE-Marking.

-- jel@jelincoln.com

 Question from my recent 3 hour webinar on the DHF ... EU MDR, and my response:

My question à Is a contract supplier who manufactures and ships a component that is used in a customer’s finished device required by FDA to have a component-level DMR?  Or is that more of a ‘if requested by the customer’ requirement?

Ans:  There's several ways to answer that.

The Specification Developer / Final Manufacturer (an FDA establishment classification) is the one who compiles the finished device documents, including the DMR (820.181 says the Manufacturer).  That is the Manufacturer who owns the device / 510(k). 

Contract manufacturers are manufacturing a device for the device "owner", so are doing it under the "owner's" documentation, per PO, and/or Contract. and/or Quality Agreement.  The same principle applies when a contract manufacturer manufacturers a device's component  or part - such manufacture is done per drawings, specs, PO, et al. developed by the top-tier manufacturer / device "owner" (usually the name on the device label)  .

In all cases, there has to be at least one DMR, the FDA CGMP requirement in 820.181, with the responsibility for compilation falling on the owner of the device, not a contractor.   

So if the customer wants a "component level DMR" that would be per a written agreement / spec / PO, et a,l between the two parties, but is not a CGMP requirement, per se. 

However, to perform the contact manufacturing of the component, the contractor would need some of their own unique documents / a partial CGMP-compliant system, mandating their own documents, such as possibly specs (could use the "owners"), drawings (could use the "owners), and  their own QC /manufacturing SOPs / WIs, equipment / operating parameters, validated, and the document that lists all those documents required for them to manufacture that part to the client's requirements. The contract manufacturer's SOPs would address what those documents and the document tying them altogether would be called (DMR / recipe / setup card ...) and how it all would be structured. 

-- jel@jelincoln.com

No need for a DHF *

* If among most US Class 1 devices, and/or the Class 2 or 3 device was developed prior to 1996-7, and no device changes made since. 

I was recently contacted by a client who was in the middle of an FDA inspection.  The Inspector was questioning why one of their product's lacked a DHF (Design History File, 21 CFR 820.30; Design and Development File, ISO 13485 7.3).  I had previously inspected that company and found no problems, and had in fact done some of their current and "retroactive" (for missing) DHFs.  I had also done some 510(k)s for them, and as part of such a project, I also did the associated DHFs, since the 510(k) draws much of its information from documentation identical to and/or contained within or referenced in the DHF. 

After the initial, typical "panic" reaction to a possible 483 observation of an area of the company we were justifiably proud of (and I had previously inspected) passed, we checked their records and verified that the product in question was developed prior to 1996-7, as proven by their 510(k) for it, and that there were no changes to it since (based on visual checks, 510(k) and current documentation comparisons, and change history data reviews; it was a needle). They did have a Device Risk Management File (per ISO 14971) for that family of products that also covered it, so that was not an inspection issue.

The Inspector took this additional information back to their office and supervisor, and then later indicated that the FDA agreed with our rationale and would not be writing a 483 observation for that issue. 

Two previous FDA inspections had never raised this issue. 

I recommended the client  add a "Memo to File" / "one page DHF" to their DHF files for this product (and any similar older, "grandfathered", unchanged product), detailing the above points, to eliminate any similar questions / challenges during future inspections. 

I also mentioned that while they were compiling such a "Memo to File / DHF", if additional provable / documented information was available that pertained to that product's development, it could certainly be so noted and included in the "Memo / DHF", for future reference and/or company IP purposes.
 

See also my blog post on "DHF's ...", dated 10/09/2017, below. 

Note:  Even for older, pre-1996-7 developed devices, I encourage companies to develop a retroactive DHF, to the degree possible, to capture available development history before it disappears due to employee turnover, retirements, deaths, etc., for IP purposes, assist in Root Cause Analysis, training, line extensions / product improvement, future 510(k)s, and similar.   

-- jel@jelincoln.com

A Key Cybersecurity Vulnerability

The easiest hacking / entry point to networked computer systems is company personnel clicking bogus links in e-mails, pop-ups, or simulated trusted sites (often with a minor change in the URL, like a "1 (one)" for an "l (el)" or "i (eye)", and similar).  Difficult to address:  Frequent reminders / traininig, IT unannounced simulations ...

- jel@jelincoln.com

 

Vulnerabilities and Risk in  Cybersecurity

FDA states that a cybersecurity vulnerability exists whenever the software provides the opportunity for unauthorized access to the network or the medical device. Cybersecurity vulnerabilities open the door to unwanted software changes that may have an effect on the safety and effectiveness of the medical device.  Failure to properly address these vulnerabilities could result in an adverse effect on public health. A major concern with OTS software is the need for timely software patches to correct newly discovered vulnerabilities in the software.

The FDA recommends that the manufacturer conduct a vulnerability analysis, both initially (premarket) and ongoing (post-market).  The approach should appropriately address the following elements: 

·         Identification of assets, threats, and vulnerabilities;

·         Assessment of the impact of threats and vulnerabilities on device functionality and end  users / patients;

·         Assessment of the likelihood of a threat and of a vulnerability being exploited;

·         Determination of risk levels and suitable mitigation strategies; and

·         Assessment of residual risk and risk acceptance criteria. 

As mentioned above, and especially software / firmware, initial design and subsequent continuous improvement activities must consider hazards / risk, per ISO 14971.  Such risk is focused on the end user – patient and/or clinician.   The hazard analysis should address both “normal" as well as “fault” risks, i.e., not just failure mode risk, the most prevalent approach, but also risk posed by the proper function of the product.  In such an analysis, the manufacturer must also consider cybersecurity as part of this regular hazard analysis. Exposure to the web, as in the networked devices focused on in this guidance, increases such cybersecurity risks to the patient / clinician.  Hazard / risk analysis’ goal is risk mitigation, documented in the Risk Management File and Report (ISO 14971), as well as in the Design History File (21 CFR 820.30).   Consider system boundaries, and connections to the external environment. In all such analysis, software must be considered with its associated hardware. 

The above is to be supplemented by on-going monitoring of actual and potential vulnerabilities,  consistent with the Quality System Regulation (21 CFR part 820), including complaint handling, internal quality audits, CAPA (corrective and preventive action), software validation and risk analysis, and servicing.  Such programs should emphasize addressing vulnerabilities which may permit the unauthorized access, modification, misuse or denial of use, or the unauthorized use of information that is stored, accessed, or transferred from a medical device to an external recipient, and may impact patient safety. 

The Agency defines critical components of such a program to include:

·         Monitoring cybersecurity information sources for identification and detection of cybersecurity vulnerabilities and risk;

·         Understanding, assessing and detecting presence and impact of a vulnerability;

·         Establishing and communicating processes for vulnerability intake and handling;

·         Clearly defining essential clinical performance to develop mitigations that protect, respond and recover from the cybersecurity risk;

·         Adopting a coordinated vulnerability disclosure policy and practice; and

·         Deploying mitigations that address cybersecurity risk early and prior to exploitation. 

Postmarket cybersecurity information may originate from an array of sources including a company’s own CAPA / warranty / complaint system,  independent security researchers, in-house testing, suppliers of software or hardware technology, health care facilities, and information sharing and analysis organizations. To manage postmarket cybersecurity risks for medical devices, a company should have a structured and systematic approach to risk management and quality management systems consistent with the CGMPs.

- jel@jelincoln.com