Linweld Software validation and Part 11

Linweld 8/2/99

Significant deviations include, but may not be limited to the following:
Failure to maintain a computer system with validated program capabilities for operating a medical gas facility [21 CFR 1-11.68]. Examples include:
No testing of the system after installation at the operating site. Operating sites are part of the overall system and lack of their qualification means the system validation was incomplete.

The validation protocol is incomplete for information needed to effectively operate a medical gas facility. For example, the protocol: (1) does not call for testing the system under worse case (e.g., full capacity) conditions; (2) lacks testing provisions to show correct functioning of the software; (3 ) mentions without explanation or supportive documentation, “historic experience” with terminals, but doesn’t specifically identify the terminals; and (4) lacks change control procedures. In addition, protocol execution on 8/93 predates protocol approval (5/94) and requirements approval (9/93).

It is necessary for you to take action on this matter now. Please let this office know in writing within fifteen (15) working days from the date you received this letter if the January 7 and March 10 letters will suffice as your response to this letter, or you may expand on those letters with additional information concerning corrections being made. If corrective action cannot be completed within 15 working days, state the reason for the delay and the time within which the corrections will be completed. We request a meeting with you to discuss your corrective action plan. Please contact Mr. Clarence R. Pendleton, Compliance Officer, telephone number (913) 752-2103 to schedule a date for this meeting.

We have received and reviewed letters dated January 7, and March 10, 1999, from Mr. Thomas L. Hileer, Director of Quality/Regulatory Affairs, which responded to the Form FDA 483 observations made at the Gerin1g, Nebraska and Topeka, Kansas facilities. We find these responses to be generally unacceptable. For example, in the March 10 letter, you:

(1) fail to recognize the basic need to include each location within the validation of the overall computer system; and

(2) acknowledge that your system, by design, does not record results that are out of specification. Only parameters that are within specifications may be recorded.
In the January 7, 1999 letter you requested specific guidance and advice from FDA as to how to go about validating your computer system. Much has been written and discussed about this subject within the pharmaceutical industry itself over the course of many years. You may wish to research that body of knowledge and, as necessary, seek technical assistance.

In addition, we request further details regarding steps your firm is taking to bring your electronic CGMIP production records into conformance with the requirements of 21 CFR, Part 11; Electronic Records; Electronic Signatures. Part 11 establishes requirements to ensure that electronic records and electronic signatures are trustworthy, reliable and generally equivalent substitutes for paper records and traditional handwritten signatures. Electronic records and electronic signatures may be used to meet record and signature requirements of 21 CFR Parts 2 10 and 211 when part 11 requirements are met. Our inspection disclosed numerous and significant deviations from part 11. Examples include:

The system does not generate an audit trail, and there is no way to determine if values have been changed on batch production records. This is important because an audit trail can be the only evidence that an electronic record has been altered. We note, for instance, that your system only records the last value entered by an operator and that values, such as Oxygen potency levels that my have been entered earlier and that may indicate potentially serious quality problems, are not recorded. The system prompts an operator when equipment detects that an Oxygen potency value is non-conforming, and permits the operator to record a value that is within specification, but does not record the original out of specification value.

No written procedures that would hold individuals accountable for actions taken under their electronic signatures. It is vital that employees accord their electronic signatures the same legal weight and solemnity as their traditional handwritten signatures. Absent such written and unambiguous policies, employees may be more apt to make mistakes, under the erroneous assumption that they will be held to a lower level of accountability than they might otherwise expect when they execute traditional handwritten signatures.

No documentation or testing of the system’s ability to discern invalid or altered records. This is significant because electronic records by their nature may be easily altered in a manner that is difficult or impossible to detect. If an employee were to alter an electronic batch record in an unauthorized manner, your system would not be able to detect such chan2e.
No documentation to show if the system has the ability to generate accurate and complete copies of records in electronic form; copies of electronic records cannot be generated at these sites. It is vital for FDA to be able to audit electronic production records by, among other things, reviewing electronic copies of your electronic records. It is therefore a serious matter that your system cannot generate such on-site electronic copies.

No safeguards to prevent unauthorized use of electronic signatures that are based on identification codes/passwords when an employee who has logged onto a terminal leaves the terminal without logging off. This is serious because another employee or individual could impersonate the individual who has already been logged on, and thereby easily falsify an electronic record. The resulting batch production record, for instance, would not be an accurate and reliable indication of the lot’s history. Moreover, in such an environment it would be fairly easy for the genuine logged on employee to disavow a signature as false, and thereby seek to avoid responsibility for actions under his/her signature (on the basis that it is fairly easy for someone else to apply his/her electronic signature.)

The untrustworthy nature of the electronic production records would make it difficult to reliably reconstruct the full history of a lot’s production in the event problems had to be investigated and solved.

We note that your electronic recordkeeping system is centralized and that all your facilities use the same procedures. This leads us to conclude that these deficiencies may be replicated throughout your organization. FDA has, on several occasions informed your company of part 11 requirements in an effort to facilitate your voluntary compliance with the regulation. For example, we advised your management of part 11: (1) during our October 1997 inspection of your Gering., Nebraska facility; and (2) by letter to you dated December 3, 1997 from Ms. Shirley J. Berryman of our Kansas City office. We are prepared to discuss part 11 issues with you further at the above referenced meeting.

SoftwareCPR keywords: gas, oxygen, drug, electronic record

About the author

Amy enjoys researching and writing about developments in medical technology and how that intersects with US law. She received her J.D. from the University of Florida Levin College of Law in 2020 and now works as a Regulatory Associate for SoftwareCPR®, a general-purpose regulatory consulting firm that is recognized globally for their expertise with standards and national regulations pertaining to medical device, mobile medical app, and HealthIT software.

SoftwareCPR Training Courses:

IEC 62304 and other emerging standards for Medical Device and HealthIT Software

Our flagship course for preparing regulatory, quality, engineering, operations, and others for the activities and documentation expected for IEC 62304 conformance and for FDA expectations. The goal is to educate on the intent and purpose so that the participants are able to make informed decisions in the future.  Focus is not simply what the standard says, but what is meant and discuss examples and approaches one might implement to comply.  Special deep discount pricing available to FDA attendees and other regulators.

3-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Brian Pate

Next public offering:  TBD

Email training@softwarecpr.com to request a special pre-registration discount.  Limited number of pre-registration coupons.

Registration Link:

TBD

 


 

Being Agile & Yet Compliant (Public or Private)

Our SoftwareCPR unique approach to incorporating agile and lean engineering to your medical device software process training course is now open for scheduling!

  • Agile principles that align well with medical
  • Backlog management
  • Agile risk management
  • Incremental and iterative software development lifecycle management
  •  Frequent release management
  • And more!

2-days onsite (4 days virtual) with group exercises, quizzes, examples, Q&A.

Instructors: Mike Russell, Ron Baerg

Next public offering: March 7 & 28, 2024

Virtual via Zoom

Registration Link:

Register Now

 


 

Medical Device Cybersecurity (Public or Private)

This course takes a deep dive into the US FDA expectations for cybersecurity activities in the product development process with central focus on the cybersecurity risk analysis process. Overall approach will be tied to relevant standards and FDA guidance documentation. The course will follow the ISO 14971:2019 framework for overall structure but utilize IEC 62304, IEC 81001-5-1, and AAMI TIR57 for specific details regarding cybersecurity planning, risk characterization, threat modeling, and control strategies.

2-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Dr Peter Rech, 2nd instructor (optional)

Next public offering:  TBD

Corporate Office

15148 Springview St.
Tampa, FL 33624
USA
+1-781-721-2921
Partners located in the US (CA, FL, MA, MN, TX) and Canada.