Medical Device Software Validation...

Information & Training. | Medical Devices | Software Validation.

All regulations related to medical device software validation are based on a premise of “good quality practices”. Quality practices must keep pace with changes occurring in the industry and up to date Software Validation practices are an integral component of good quality practice.

What are the various problem areas that arise in a validation?

There may be a lack of or incomplete validation plans. The documented system requirements and design documents may be poorly drafted. There may be an inability to track requirements through the development life cycle. The software or validation might suffer from poor configuration management. Again procedures and manuals may be lacking in detail, missing key requirements. There may be incomplete test cases and test protocols, etc..

FDA Medical Device Regulation. Outline of the FDA regulatory requirements.
FDA Medical Device Classification. The FDA approach to Medical Device Classification.
EU Medical Device Regulation and Classification (per MDD’s).
^New European Medical Device Regulations (MDR’s). MDR Classification. MDR General Safety requirements.
Current Good Manufacturing Practices. QSR’s. General requirements of the QSR’s.
Quality System requirements to maintain compliant Validations.
Medical Device Process Validation. Validation requirements. Protocol development. IQ. OQ. PQ.
Medical Device Software Validation.
Medical Device Design Validation.
Electronic Signature, Electronic Records.
Life Cycle Approach to Validation.
Risk Identification. Documentation. DHR’s. DMR’s.
Etc. Etc. …
Information & Training presentation >>>

The Validation Plan.

There is a need to draft a validation plan. The validation plan will define who is responsible, i.e. it will define the validation team. The plan will also define the computer or software system. Normally a flow diagram of the current and proposed systems will be created. The functional requirements will be defined. The software development methodology will be outlined. The plan will then go on to outline the system specifications, are the proposed specifications adequate to meet the required functional requirements, will the level of documentation be acceptable? What will be the test process, how will document, software and hardware change control be achieved? What will be the agreed configuration management? What is the current standard operating procedure for software validation, how does it define proposed “new system” for “old system” change procedures? Etc..

The Standard Operating Procedures for Validation needs to consider aspects such as:

• What is the system operation.
• What is the backup procedure.
• How will change control be implemented.
• The process for handling of source code.
• The frequency of revalidation and the extent of any revalidation.
• How will the hardware maintenance be implemented.
• The process for software maintenance and software enhancements.
• The process for raw data management.
• The identification and implementation of training needs.
• The standard operating procedure (SOP) for system crash and recovery.
• How will security be implemented and compliance requirements (i.e. 21 CFR part 11 compliance).

Note: The FDA’s 21CFR Part11 requires special attention and has been the focus of much discussion especially on questions such as hybrid systems, non durable storage media, recording of audio data, etc..

Looking at software security, you need to consider:

• Access for the system.
• Who can implement data changes.
• What is the back-up procedure.
• Frequency, duration and extent of archiving.
• System failure and recovery practices.

Vendor Supplied Software.

Looking at vender supplied software, there will be a need to audit any potential vendor. You need to consider their software development SOPs. What programming standards do they apply. The effectiveness of their software quality assurance program and what audit issues have arisen during your own audit? There will also be a need to consider the vendor history. What has been their market history, are you aware of the experiences of their previous customers and is the profile of their previous customers similar to our own profile.

When considering potential software vendors you need to:

• Look at all manufacturing processes.
• Identify the critical processes.
• Develop a plan for validation:
– New and old systems
– Set priorities
• Establish a vendor audit program:
– Have specific requirements based on the type of product purchased.
• Have good documentation and rationale for validation practices:
– Development (who is on the team?)
– Implementation
– Level of testing
• Be Proactive – Don’t Wait for external auditors (or customers) to find problems.

Information & Training.

Medical Device:

- - Validation. Classification. Regulation. Requirements. Current best practices.
  - FDA cGMP’s. EU MDR’s / MDD’s.
  - FDA Medical Device Regulation. Outline of the FDA regulatory requirements.
  - FDA Medical Device Classification. The FDA approach to Medical Device Classification.
  - EU Medical Device Regulation and Classification (per MDD’s).
  - ^New European Medical Device Regulations (MDR’s). MDR Classification. MDR General Safety requirements.
  - Current Good Manufacturing Practices. QSR’s. General requirements of the QSR’s.
  - Quality System requirements to maintain compliant Validations.
  - Medical Device Process Validation. Validation requirements. Protocol development. IQ. OQ. PQ.
  - Medical Device Software Validation.
  - Medical Device Design Validation.
  - Electronic Signature, Electronic Records.
  - Life Cycle Approach to Validation.
  - Risk Identification. Documentation. DHR’s. DMR’s.
  - Etc. Etc. …
  - Information & Training presentation >>>