Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Process and Regulated Processes Software Validation Elements

Medical device manufacturers operate in a competitive marketplace with increasing end-user demands for features and usability and 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.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Process and Regulated Processes Software Validation Elements

  1. 1. Process and Regulated Processes Software Validation Elements Arta Doci Managing Director, Quality Arete Group
  2. 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 Quality Arete Group 10/13/2014 2
  3. 3. For what systems does FDA require Software Validation? Software that is part of the: 1. Manufacturing Process 2. Quality System 3. Medical Device Quality Arete Group 10/13/2014 3
  4. 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 10/13/2014 4
  5. 5. 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
  6. 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 10/13/2014 6
  7. 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 Quality Arete Group 10/13/2014 7
  8. 8. 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
  9. 9. 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. Quality Arete Group 10/13/2014 9
  10. 10. Validation of Non Device Software Quality Arete Group 10/13/2014 10
  11. 11. 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 Quality Arete Group 10/13/2014 11
  12. 12. Validation of Non Device - Spreadsheet 1. Intended Use and Requirements 2. Design and Implementation 3. Test 4. Maintenance 5. Retirement Quality Arete Group 10/13/2014 12
  13. 13. 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 Quality Arete Group 10/13/2014 13
  14. 14. Validation of Device Software Quality Arete Group 10/13/2014 14
  15. 15. 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
  16. 16. 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 Quality Arete Group 10/13/2014 16
  17. 17. Laboratory Information Management System (LIMS) Validation A Case Study Quality Arete Group 10/13/2014 17
  18. 18. Topics  LIMS System Goals  Software Development Lifecycle  Security  Disaster Recovery  Risk Approach  Requirements Elicitation; Analysis; Validation; Management.  Software Verification  Software Validation Quality Arete Group 10/13/2014 18
  19. 19. 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. Quality Arete Group 10/13/2014 19
  20. 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 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
  21. 21. 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 Quality Arete Group 10/13/2014
  22. 22. 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 Quality Arete Group 10/13/2014 22
  23. 23. 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. Quality Arete Group 10/13/2014 23
  24. 24. 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 Quality Arete Group 10/13/2014 24
  25. 25. 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 Quality Arete Group 10/13/2014 25
  26. 26. User Needs Requirements Quality Arete Group 10/13/2014 26
  27. 27. Requirements Quality Arete Group 10/13/2014 27
  28. 28. 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? Quality Arete Group 10/13/2014 28
  29. 29. 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. Quality Arete Group 10/13/2014
  30. 30. Software V&V Quality Arete Group 10/13/2014 30
  31. 31. 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 Quality Arete Group 10/13/2014 31
  32. 32. Software Testing Cycle Example Quality Arete Group 10/13/2014 32
  33. 33. 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 Quality Arete Group 10/13/2014
  34. 34. 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 Quality Arete Group 10/13/2014 34
  35. 35. 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. Quality Arete Group 10/13/2014 35
  36. 36. 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 Quality Arete Group 10/13/2014
  37. 37. Scenario
  38. 38. 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. Quality Arete Group 10/13/2014 38

    Be the first to comment

    Login to see the comments

  • MarkMiller91

    Aug. 3, 2015
  • nirbennun7

    Sep. 3, 2015
  • pw_share

    Jan. 20, 2019
  • SudheerVanguri1

    Jan. 21, 2020

Medical device manufacturers operate in a competitive marketplace with increasing end-user demands for features and usability and 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.

Views

Total views

2,022

On Slideshare

0

From embeds

0

Number of embeds

4

Actions

Downloads

71

Shares

0

Comments

0

Likes

4

×