1. Hello and Welcome to The Quality Forum Online...Continuing in the spirit of People Helping People !
    Dismiss Notice
Dismiss Notice
You must be a registered member in order to post messages and view/download attached files in this forum.
Click here to register.

How do I validate our ERP system?

Discussion in 'ISO 13485 and ISO 14969 – Medical Devices QMS' started by Nikki, Apr 12, 2016.

  1. Nikki

    Nikki Well-Known Member

    Joined:
    Jul 31, 2015
    Messages:
    254
    Likes Received:
    137
    Trophy Points:
    42
    Location:
    Maine
    Hello All -

    This may be a silly question - but I would like to get the opinions of you all to make sure we do this validation the right way.

    We are currently a paper-based system. Paper Order Trackers are used to track the whole job, including who took the order, who ran the job, who mixed it, who inspected it, who shipped it - EVERYTHING. We are moving towards a CUSTOM made electronic system. No more paper.

    We have not conducted much validation on anything - and I know software needs to be validated. What is the simplest, but best way to validate this type of software?

    Do we go through a few trial runs using the software and just cross check to make sure nothing is missed? If so, how many trials are a good amount? We produce around 250 lots a month...

    Thoughts?

    Thank you in advance!
    -Nikki
     
    AcTouch likes this.
  2. Roberticus

    Roberticus New Member

    Joined:
    Aug 10, 2015
    Messages:
    2
    Likes Received:
    2
    Trophy Points:
    2
    Hmmm, never quite had to validate an entire ERP system when I worked in medical device, though I did have to conduct similar efforts for our Preventive Maintenance (glorified Access database) software, Access databases which stored final inspection procedures (and records), Adobe Acrobat for DHR scan & storage, programmable table top vision systems, and certain Excel spreadsheets which calculated Ppk or GR&R.

    Defining user (your) requirements, i.e. what (QMS) processes are controlled by this software, is an essential place to start.

    From there one can generally go the IQ/OQ/PQ route. For each of these steps, we would compose a protocol which defined the requirements, criteria for acceptance, and reference instructions/ documentation, and obtain cross-functional management (and Customer?) approvals. After executing the planned testing/ answering the checklist questions for compliance per the protocol, results, and any deviations from plans are outlined in a report which also indicates whether results are overall acceptable, and reports are approved by protocol approvers.

    Essentials for the IQ phase: software identification and revision control, data storage and backup arrangement, controls of access to system data (and verifibility of who/ when data is altered), identification of compatible users' hardware, compatibility of accessories (barcode scanners, label printers, data entry aids or attached gaging), adequate server hardware per manufacturer's specifications.

    OQ phase: define the tasks the system is used for, trial runs to determine functionality, ensure adequate work instructions are developed for consistent execution of tasks, testing of data integrity per plan defined in IQ stage

    PQ phase: challenge the system to ensure robustness. Will system require multiple people to utilize at once? If so, trials of function with multiple users inputting at once. Identify risks (likely through FMEA or FTA) to system stability and test out against them, including entry controls which assure that a response is present, or programmed controls for proper coding or formatting of input data. Determine method and frequency for revalidation/ validation review.

    Regarding sample size, we generally didn't do a full "power and sample size" routine like we did for dimensional product data, we seemed to get by with 3 distinct trials or test cases for transactional tasks within the software. You may want to do something statistical to sample records created by the software. Use risk-based rationale to justify heightened or minimal testing.

    Hope this gets you started, I'm sure others will have more details...
     
    John C. Abnet and Nikki like this.
  3. Candi1024

    Candi1024 Well-Known Member

    Joined:
    Jul 30, 2015
    Messages:
    129
    Likes Received:
    83
    Trophy Points:
    27
    Location:
    Pennsylvania
    Well, I'll be validating a new ERP system sooner or later. Implementation is currently 2 years behind, lol!

    However, I am not the person writing the protocols. Someone at another location that is currently implementing the system is. I will simply be executing the protocols. And I have yet to see them.

    I would assume they will be similar to other software validations I have completed. Run through some examples and verify that the expectations are met. Information entered one place is moved to another location and is correct, reports print the correct information, searches yield the correct information. When you select an option, the correct thing happens, navigation through the system works, ect. For us we would do one validation per product type. Sample size doesn't necessarily correlate here. It helps if you know the in's and out's of the software so that you know where mistakes could happen. Data tables should be reviewed....

    Software validation is not fun. Sometimes you can pay the software company to write the validations for you, and you approve the protocol and execute. That may be of value to you if you are unfamiliar with software. It isn't cheap though.
     
    AcTouch, Nikki and Roberticus like this.
  4. Candi1024

    Candi1024 Well-Known Member

    Joined:
    Jul 30, 2015
    Messages:
    129
    Likes Received:
    83
    Trophy Points:
    27
    Location:
    Pennsylvania
    This may help, or completely confuse you!
     

    Attached File(s): 1. Scan for viruses before using. 2. Report any 'bad' files by reporting this post. 3. Use at your own Risk.:

    AcTouch likes this.
  5. Xavier Canals-Riera

    Xavier Canals-Riera New Member

    Joined:
    Jan 10, 2016
    Messages:
    3
    Likes Received:
    0
    Trophy Points:
    1
    Consider to use the GAMP guidelines by ISPE

    s
     
  6. David Bradley

    David Bradley Active Member

    Joined:
    Aug 2, 2015
    Messages:
    57
    Likes Received:
    54
    Trophy Points:
    17
    Location:
    Michigan
    For those who might not be aware:
    IQ = Installation Qualification
    OQ = Operational (sometimes also referred to as Operator) Qualification
    PQ = Performance Qualification
     
    AcTouch likes this.
  7. AcTouch

    AcTouch New Member

    Joined:
    Aug 14, 2017
    Messages:
    1
    Likes Received:
    0
    Trophy Points:
    1
    Good :)))
     

Share This Page