Process and Regulated Processes Software Validation Elements

Process and Regulated Processes Software Validation Elements

Arta DociManaging Director, Quality Arete Group

04/12/2023Quality Arete Group 2

Agenda• For what systems does FDA require Software

Validation?• Regulatory Requirements• Benefits of Software Validation• Intended Use and the Requirements for Fulfilling

Intended Use• Design Controls• Product Development Process with Design Controls• Validation of Non Device Software• Device Software Validation• Device Software Validation – Case Study


For what systems does FDA require

Software Validation?

Software that is part of the:1. Manufacturing Process2. Quality System3. Medical Device

04/12/2023 4

Requirements

• The production and Process Control subpart of the QSR for medical devices requires that software be validated and that process include appropriate risk analysis

• Establish a software life cycle model. The model should cover the software lifecycle from design to retirement.

• Whenever computers or automated data processing systems are used as part of production or the Quality Systems, manufacturers must validate the software for its intended use according to an established protocol

• All software changes must be validated before approval and implementation

• The procedures of the validation and its results must be documented

Quality Arete Group


Benefits of Software Validation

• Decrease failure rates• Fewer consumer complaints• Fewer recalls and corrective actions• Less risk to patient• Reduced liability to manufacturers

Critical tool to ensure regulatory requirement, product quality, and product reliability. In addition, it can reduce long term costs by making it easier and less costly to reliably modify

software and revalidate software changes

04/12/2023 6

Intended Use and the

Requirements for Fulfilling

Intended Use• Intended use for a medical device is usually related to

a diagnostic or therapeutic use, and ancillary use from other stakeholders.

• Intended use for non device software (software that automates part of the production or quality system) – describes the part of the production or quality system that it automates.

• Components of intended use:o Who uses the software?o Where is the software used?o When is the software used in the process?

• Requirements are Verified; Intended Use is Validated• Requirements Support Intended Uses

Quality Arete Group

Quality Arete Group 7

Design Controls - 820.30 (a)

Required Elements Design Inputs Design Outputs Design Review Design Verification Design Validation

Design Validation Risk Analysis Software Validation

Design Transfer Design Changes Design History File

04/12/2023


Product Development Process

(example)

Concept Feasibility Development

Qualification Launch

Design Verification

Design Outputs

Design Transfer

Design Inputs

Design Validation

Design History File

Risk Management

Design Control Change

04/12/2023


Validation

FDA: Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting predetermined specifications and quality attributes.

ISO-9000-2005: Confirmation by the provision of objective evidence that the requirements for a specific use or a specific intended application have been met.

EU GMP Guideline: Establishment of evidence in accordance with the rules of ”Good Manufacturing Practice” that procedures, processes, items of equipment, materials, operations or systems do in fact result in the intended outcomes.

WHO: Establishing of documented evidence which provides a high degree of assurance that a planned process will consistently perform according to the intended specified outcomes.

04/12/2023


Validation of Non Device Software

04/12/2023 11

Validation of Non Device Software

1. Life Cycle Planning (Determine the lifecycle model to use)

2. Needs and Requirements Identification3. Product & Vendor Selection4. Acquisition5. Test6. Deployment and Training7. Maintenance8. Retirement

Quality Arete Group


Validation of Non Device -

Spreadsheet

1. Intended Use and Requirements2. Design and Implementation3. Test4. Maintenance5. Retirement


Example: Spreadsheet Validation

• Protect data throughout the data retention periodo Password protectiono Audit trailso Electronic signatureso Security – limited accesso Test calculations, test macros, and VBA scripts o Code (version control) management


Validation of Device Software


Software Development ProcessRepeatable and efficient process that supports the development of a safe and effective medical device compliant with applicable regulations and standards.

IEC 62304:


Software Development Process …

• Software Development Planning – processes used in development, deliverables developed, configuration management, software system verification

• Software Requirements Analysis o Risk Management – identify possible hazards and mitigations to be addressed by

softwareo Software Requirements – expected behavior of the software system (Software

requirements document and Trace Matrix)o Software specifications – critical design decisionso Software safety classification

• Software Architecture Design• Software Detailed Design• Software Unit Implementation and Verification• Software Integration and Integration Testing• Software System Testing• Software Release• Software Maintenance


Laboratory Information Management System (LIMS) Validation

A Case Study


Topics

LIMS System Goals Software Development Lifecycle Security Disaster Recovery Risk Approach Requirements Elicitation; Analysis; Validation; Management. Software Verification Software Validation

04/12/2023


Goals: Software Focus

System validation of the Java-Based server system application, which supports management of diverse clinical studies, and ensures: Clinical Data Entry and Validation Data Extraction Study oversight, auditing, and reporting Trial Database is complete, accurate, and a true

representation of what took place in the trial Trial database is sufficiently clean to support the statistical

analysis and its interpretation.

04/12/2023

04/12/2023 20

Goals: Ensure Data Quality“Data quality” refers to the essential characteristics of each piece of data; in particular, quality data should be:• Accurate

o Trial database accurately captures the source datao Any corrections or changes are documentedo Audit trail

• Legibleo Clear handwriting on CRFso Do not obliterate information when making changes/correctionso All data (including meta-data and audit trails) must be in human-readable form

• Complete and Contemporaneouso Avoid blank data fields or provide explanation (e.g. unknown, unobtainable, not applicable)

o Data must recorded at the time the activity occurs

o Audit trails to provide evidence of timing

• Originalo Original data (e.g. lab results, study questionnaires

o Accurate transcriptions of source data

• Attributable to the person who generated the datao Who recorded the information

o Only designated study staff should have access to data

o Audit trail!

WHO Handbook for Good Clinical Research Practice (GCP) : Guidance for Implementation, 2005Quality Arete Group

Software Development Lifecycle (example)Adapted from GAMP V-Model

21

User Requirement Specification (URS)

User Acceptance Testing, Validation (UAT, Val. Prot.)

Validation and Verification Testing (RN, Ver. Prot.)

System Testing(Regression)

Integration Testing (I&T)

Unit Testing(Junit, Nunit, etc.)

Verification

Informal Verification

Software Requirement Specification (SRS)

Software Architecture Specification (SAS)

Detailed Design Document (DDD)

Build (Coding, Config., Customization)

Business Owner

Software Engineering

Quality Assurance

Design Verification

Verification

Confirmation that the software is built correctly (to

specification)

ValidationConfirmation that the right software was built (satisfies

requirements)



Validation

04/12/2023Quality Arete Group


Security - Limited Access

• Each user of the system has an individual account• The user logs in their account at the beginning of a data

entry session, inputs information (including changes) on the electronic record, and logs out at the completion of data entry session

• The system limits the number of log-in attempts (3) and records unauthorized access log-in attempts

• The system does not allow an individual to log onto the system to provide another person access to the system.

• Passwords or other access keys be changed at established intervals commensurate with a documented risk assessment

• System automatically logs user off for long idle periods. For short periods of inactivity, an automatic screen saver prevent data entry until a password is entered


Security – Audit Trails

• System generates computer-generated, time-stamped audit trails related to the creation, modification, or deletion of electronic records and may be useful to ensure compliance with the appropriate regulation.

• Audit trails describe when, by whom, and the reason changes were made to the electronic record.


Disaster Recovery

• Implemented a disaster recovery policy and backed up data in regular intervals.

• Mirrors provided an alternative means of accessing key components of software, should primary servers be temporarily unavailable


Risk Approach

Three main areas that could cause your clinical study data to be at risk:System LIMS behaves as expectedProcess Quality control steps, SOPs, policyAccessibility People, roles, restricted access to

the clinical study data


User NeedsRequirements


Requirements


Requirements Checking

Validity. Does the system provide the functions which best support the customer’s needs?

Consistency. Are there any requirements conflicts?

Completeness. Are all functions required by the customer included?

Realism. Can the requirements be implemented given available budget and technology

Verifiability. Can the requirements be checked?


Example Requirements

SRS 1

LIMS SHALL ASSIGN ACCESSIONING NUMBER USING THE FOLLOWING FORMAT:“VSL<LABID>CYYYYMMDD-XXX”. WHERE <LABID> EQUALS A UNIQUE IDENTIFIER FOR THE LAB AND YYYYMMDD EQUALS TODAY’S DATE AND XXX EQUALS 001 FOR THE FIRST SAMPLE OF THAT DAY AND INCREMENTS BY 1 FOR EACH ADDITIONAL SAMPLE THAT DAY.

SRS 2

LIMS shall display a barcode printer selection dialog that lists available barcode printers.

SRS 3

LIMS shall display an error if the user does not select a barcode printer.

SRS 4

LIMS shall display an error if the selected barcode printer is not found.


Software V&V


Software V&V

Verification: "Are we building the product right"The software should conform to its specification

Validation: "Are we building the right product"The software should do what the user really requires

GOALS: Verification and validation should establish confidence that

the software is fit for purpose This does not mean completely free of defects Rather, it must be good enough for its intended use

The type of use will determine the degree of confidence that is needed


Software Testing Cycle Example


Requirement Validation

Via Test Case Generation

Enter 2 samples to add and click the “Submit” button.

Verify LIMS adds correct number of samples and assigns accessioning numbers in this format:“VSL<LABID>YYYYMMDD-XXX” where(a) <LABID> Equals ‘C’ (b) YYYYMMDD equals today’s date (c) XXX equals 001 for the first sample of that day

and increments by 1 for each additional sample that day.

SRS 1

Click on Task # 2. Visually inspect the GUI and verify LIMS displays the Update Shipping Info screen.

Enter "Update Shipping Info" and check the “Replicate” button.

Visually inspect the GUI and verify LIMS moves to next task.

Click on Task # 3. Verify LIMS displays the barcode printer selection dialog that lists available barcode printers.

SRS 2

Click Cancel (Do not select any of the printers)

Verify an error dialog box displays informing the user that a barcode printer much be selected.

SRS 3


Tools

• Subversion: Code Management• JIRA: Defect Tracking and Requirement

Traceability• JTest: Testing and static code analysis• Spreadsheets: Use data to make quality and

GxP decisions• Minitab: Software FMEA and Trial Randomization• LIMS: (Clinical) Laboratory Information

Management System


Test Cases

Test case examples:• Direct Entry of Data:

o Test all the prompts, flags, or other help features into your computerized system to encourage consistent use of clinical terminology and to alert the user to data that are out of acceptable range.

o Use programming features that permit repopulation of information specific to the subject.

• Retrieved data regarding each individual subject in a study is attributable to that subject. o Test: Reprocess data from a study that can be fully reconstructed from

available documentation.


ConclusionIn addition to operating in a competitive marketplace with increasing end-user demands for features and usability, medical device manufacturers operate in a highly regulated environment.

Regulatory bodies look for evidence that medical devices are developed under a structured, quality-oriented development process. By following software validation and verification best practices, one can not only increase the likelihood that they will meet their compliance goals, they can also enhance developer productivity.

Scenario


Scenario:A diagnostic company, after having visited several times buy vs. in-house option for a Clinical Data Management System, has decided to implement in-house a custom software application to manage clinical trial data and analysis. The requirements for the software are not fully identifiable in advance; therefore, continual feedback from the Clinical Development and Laboratory Operations groups will be needed.

Define the elements and supporting content that would be needed to meet software validation regulatory requirements. Establish approach and provide details needed to complete a validation plan for the following example.

o Please note if additional information is needed to properly define plan.o Use either FDA guidance or ISO standards in helping to define process

validation activities.

Devices & Hardware

Process and Regulated Processes Software Validation Elements