Process and Regulated Processes Software Validation Elements

Process and Regulated Processes
Software Validation Elements
Arta Doci
Managing Director, Quality Arete Group

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
Quality Arete Group 10/13/2014 2

For what systems does FDA require
Software Validation?
Software that is part of the:
1. Manufacturing Process
2. Quality System
3. Medical Device

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

Benefits of Software Validation
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
• Decrease failure rates
• Fewer consumer complaints
• Fewer recalls and corrective actions
• Less risk to patient
• Reduced liability to manufacturers
10/13/2014 5
changes
Quality Arete Group

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

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

Product Development Process (example)
Concept Feasibility Development Qualification Launch
8
Risk Management
Design Outputs
Design Verification
Design Transfer
Design Inputs
Design Validation
Design Control Change
Design History File
Quality Arete Group 10/13/2014

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.

Validation of Non Device
Software

Validation of Non Device Software
1. Life Cycle Planning (Determine the lifecycle model
to use)
2. Needs and Requirements Identification
3. Product & Vendor Selection
4. Acquisition
5. Test
6. Deployment and Training
7. Maintenance
8. Retirement

Validation of Non Device - Spreadsheet
1. Intended Use and Requirements
2. Design and Implementation
3. Test
4. Maintenance
5. Retirement

Example: Spreadsheet Validation
• Protect data throughout the data retention period
o Password protection
o Audit trails
o Electronic signatures
o Security – limited access
o Test calculations, test macros, and VBA scripts
o Code (version control) management

Validation of Device
Software

Software Development Process
Repeatable and efficient process that supports the development of a safe and effective
medical device compliant with applicable regulations and standards. IEC 62304:
10/13/2014 15
Quality Arete Group

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 software
o Software Requirements – expected behavior of the software system (Software
requirements document and Trace Matrix)
o Software specifications – critical design decisions
o 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

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.

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 data
o Any corrections or changes are documented
o Audit trail
• Legible
o Clear handwriting on CRFs
o Do not obliterate information when making changes/corrections
o All data (including meta-data and audit trails) must be in human-readable form
• Complete and Contemporaneous
o 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
• Original
o Original data (e.g. lab results, study questionnaires
o Accurate transcriptions of source data
• Attributable to the person who generated the data
o 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 Quality Arete Group Implementation, 2005 10/13/2014 20

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.)
Validation
Verification
Informal
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
Verification
Confirmation that the software is
built correctly (to specification)
Validation
Confirmation that the right software
was built (satisfies requirements)
Informal
Verification

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 expected
Process Quality control steps, SOPs, policy
Accessibility People, roles, restricted access to
the clinical study data

User Needs
Requirements

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
29
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
33
• 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.

Conclusion
In 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.
36

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.

Process and Regulated Processes Software Validation Elements

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Process and Regulated Processes Software Validation Elements

Similaire à Process and Regulated Processes Software Validation Elements (20)

Dernier

Dernier (20)

Process and Regulated Processes Software Validation Elements