1. Assessing System Validation
Requirements for OHS
iPatches/Bugs
Steven Halpern & Jane Hamilton
Application Support Team
bscassist@biopharm.com
Phone: 407.539.6207
2000 Alameda de las Pulgas, Suite 154
San Mateo, California 94403-1270

2. Introduction
Review iPatch
Evaluate Risk
Action Needed/Regression Testing
Decide if Installing
Modify and/or Create Test Cases
Execute Validation Scripts

3. Reminder!
The formulas and definitions used in this
presentation are only examples created for
this presentation.
Always follow company
policies/procedures with regard to
installation, risk assessment, regression
analysis & testing, validation,
documentation, etc.

4. Smile, you’re on Candid Camera
The bug/”fly on the
wall” tells us if you
attended last year…
“Super Steven’s”
candid camera helps
too 

5. Review iPatch (Download)
My Oracle Support (formerly MetaLink)
https://support.oracle.com/CSP/ui/flash.html
Select Patches & Updates tab
Select Product
Select Version
Select Platform
Click Search Button

6. Review iPatch
Click on the Patch ID link of interest

7. Review iPatch
Click Read Me to view ReadMe

8. Review iPatch (Assess)
Example of partial list of individual bugs from iPatch 4.5.3.23:
Application/Patch Bug # Assessment
OC/RDC 4.5.3.23 9156336 Modifications to form entry in RDC – adding visit or page
8418162 Modifications to user profile – login attempts
6811143 Modifications to the RDC Classic Activity List
9070336 Modifications to RDC Onsite test mode
8754103 Modifications to PDF entry
7388447 Modifications to Group Approval or Verification in RDC Onsite
6899265 Modifications to print an HTML CRF
“Kill 2 bugs with 1 patch” “Kill several bugs with 1 patch”
sounds so much better than sounds even better
“Kill 2 birds with 1 stone”

9. Review iPatch (Notes)
If a new iPatch obsoletes a previously uninstalled iPatch,
all bugs from obsolete iPatch need to be assessed.
If a new iPatch obsoletes a previously installed iPatch, all
bugs from obsolete iPatch DO NOT need to be assessed.
Determine to what Patchsets/iPatches the system is
currently patched and assess any newer iPatches that
have not been installed.
Note: The iPatches are not necessarily released in chronological order
To get the list of applied Patchsets/iPatches, go to Help->
About within the application (see next slide):

10. Review iPatches Installed
Help => About
•Applications on top
•Databases on bottom

11. Just for Fun: Fact
What does the “i” in iPatch stand for?
A. Individual
B. Incremental
C. Eye – Eye
D. Insect Repellent
E. Invisible

12. Answer
What does the I in iPatch stand for?
A. Individual
Technically i = individual, however, an individual patch does not
mean it contains ONE fix. It contains one or more fixes, yet
does not have enough fixes to be a patch Set.
Types of Patches:
•iPatch = Incremental fixes of the Application
•PatchSet = Collections of iPatches plus additional fixes

13. Evaluate Risk
Risk - Potential harm or effect on the system validation arising from
applying patches multiplied by the impact to business process
Effect:
Yes (1) The bug affects the subsystem
No (0) The bug does not affect the subsystem
Impact:
Yes (1) Subsystem is used in the business process
No (0) Subsystem is not used in the business process
Risk Calculation*:
Effect Impact on Business
NO (0) YES (1)
*Any risk that results in a
YES (1) No Risk Risk
(0 x 1) = 0 (1 x 1) = 1
score of 1 should be
NO (0) No Risk No Risk considered as impacting
(0 x 0) = 0 (1 x 0) = 0 the system validation.

14. Evaluate Risk
Example of partial list from iPatch 4.5.3.23:
Application/Patch Bug # Assessment Risk
OC/RDC 4.5.3.23 9156336 Modifications to form entry in NO– SOPs do not allow for periods
RDC – adding visit or page in DCI Short Names
8418162 Modifications to user profile – YES
login attempts
6811143 Modifications to the RDC YES
Classic Activity List
9070336 Modifications to RDC Onsite YES
test mode
8754103 Modifications to PDF entry NO - PDF entry is not used
7388447 Modifications to Group YES
Approval or Verification in RDC
Onsite
6899265 Modifications to print an HTML YES
CRF

15. Action Needed
Regression Testing - The process of verifying that any
iPatch applied to validated software programs does not
produce additional errors and the validated software still
performs as expected after the iPatch is applied
For each bug:
• What subsystem or modules are impacted?
• What subsystem or modules require retesting?
• What test case from original validation scripts can be used?
• Will test cases need to be modified/created?

16. Action Needed
Example of partial list of individual bugs from iPatch 4.5.3.23:
Application/Pa Bug # Assessment Risk Regression
tch
OC/RDC 4.5.3.23 9156336 Modifications to form No: SOPs do not allow for Testing is not required
entry in RDC – adding periods in DCI Short
visit or page Names
8418162 Modifications to user Yes Testing is required
profile – login attempts
6811143 Modifications to the Yes Testing is required
RDC Classic Activity
List
9070336 Modifications to RDC Yes Testing is required
Onsite test mode
8754103 Modifications to PDF No: PDF entry is not used Testing is not required
entry
7388447 Modifications to Group Yes Testing is required
Approval or Verification
in RDC Onsite
6899265 Modifications to print an Yes Testing is required
HTML CRF

17. Decide if Installing
To ‘bee’ bugged or debugged, that is the question
For each iPatch, decide if it is worth installing:
• Does the bug affect your present system?
• Will the bug affect your system in the future?
• Does your company use that part of the application?
• Will your company use that part of the application in the future?
• …?
If I wear my You bet.
iPatches, will I be iPatches have
safe from beeing saved our lives !
de-bugged ?

18. Modify and/or Create Test Cases
for Regression Testing
Assumptions:
•System has previously been validated
•Smoke test and validation scripts used for validation are available
If iPatches touch subsystems included in the smoke tests,
then re-running the smoke test is sufficient.
If iPatches touch subsystems not included in the smoke
tests, then:
• Modify Test Cases
• Extract certain sections and make them stand alone
• Create New Test Cases
• New functionality

19. Modify and/or Create Test Cases
Test Case Format Example:
General Document Sections
• Purpose
• Intended Audience
• Revision History
• Approval Signatures
• Table of Contents
Test Case
• Title
• System Details
• Objective
• Individual Steps
• Instructions
• Expected Results
• Actual Results including Pass/Fail
• Results including Tester and Reviewer Signatures

20. Test Case Examples

21. Test Case Examples

22. Execute Validation Scripts
1. Prepare system for validation
2. Follow any relevant documentation (e.g.; test plan)
3. Execute the existing, modified, and/or new test cases
4. Create any relevant documentation (e.g.; test plan summary)
5. Sign off on system validation

23. Acknowledgements
BioPharm Systems, Inc.
• Alex Sefanov
• Lori Venable
• Kay Laskowski
“The way we play a game shows some of our character.
The way we lose shows all of it.”
When we work together, we win!
Winning is fun!