Software Development in Regulated Environments

How to survive the FDA

Dr. Sasha Göbbels
https://shrtr.name/sire/

Overview

  • Short (!) about me
  • What are we talking about?
  • Medical Systems - GAMP 5
  • Practical Approach
  • References

About me

  • Senior Engineering Manager
  • PhD in Theoretical Chemistry
  • ADHD, hyperfocus topics include:
    • Diversity & Inclusion
    • Fashion Theory& Fashion
    • Neuroscience & Empathy
  • Extroverted introvert
  • Trans femme

What are we talking about?

Paul McNulty
Former US Deputy
Attorney General
If you think compliance is expensive - try non-compliance.

What is regulation?

Regulation is the management of complex systems according to a set of rules and trends.
Source: Wikipedia
  • Regulation is dependent of national law and maybe EU
  • Regulatory norms and standards are set by engineering institutions or lawmakers
  • Sometimes national institutions adopt regulations from other countries
  • In software development: your customer will insist on a validated product/process

Examples for regulated industries

Medical: FDA, BfArM
Financial: FINRA, BAFIN
Aerospace: FAA, EASA

Regulation in industry

  • Not every part of an industry is regulated
  • Regulation applies where damage can be caused
  • Regulation always consists of 2 parts:
    1. Where does regulation apply?
    2. What are the rules if it applies?

In this talk

  • We'll talk about medical systems
  • They are among the most tightly regulated
  • Please ask me about other industries
  • This is not a GMP training, just an overview!

Medical Systems - GAMP 5

A Glossary

GMP - Good Manufacturing Practice
GAMP - Good Automated Manufacturing Practice
SOP - Standard Operating Procedure
SME - Subject Matter Expert
QMS - Quality Management System(s)
ISPE - Int. Society for Pharmaceutical Engineering
FMEA - Failure Mode and Effects Analysis

Examples for medical systems requirements

  • DIN EN ISO 13485:2016-08 - QMS General requirements
  • FDA 21 CFR Part 211.68 - Automatic, mechanical & electronic equipment
  • FDA 'Annex 11' - Computerized systems
  • GAMP 5 - A Risk-Based Approach to Compliant GxP Computerized Systems

Definition of a computerized system

A computerized system is a combination of software and hardware components that together perform certain functions.
Source: FDA 21 CFR Part 211.68, Annex 11

Definition of validation

Documented evidence that a specific process continuously produces a product that meets predefined specifications and quality characteristics with a high degree of certainty.
Source: FDA 21 CFR Part 211.68

Focus on GAMP 5

Some remarks on GAMP 5

  • GAMP 5 is an industry standard, not a law
  • In computerized systems GAMP 5 is today the standard
  • Validation ≡ qualification
  • Validation also includes user training and environment validation
  • The process includes all phases of a product, even the decommissioning/shutdown

Five key concepts

  1. Product and process understanding
  2. Life cycle approach within a QMS
  3. Scaleable life cycle activities
  4. Science based quality risk management
  5. Leveraging supplier involvement

The Systems Process

The Software Process

GAMP 5 categories

Cat. Name Description Examples
HW 1 Std. comp. Built in high quantities Router, SPS
HW 2 Cust. comp. Indiv. hardware in low quantities Indiv. control unit
SW 1 Infrastructure Shrink wrapped software OS, Office, DBMS
SW 2 Firmware Not used any more, see 1 & 3 OS of a switch
SW 3 Non-configurable prod. Comm. software that needs no config Barcode scanner, temp. sensor
SW 4 Configurable prod. Std. software that needs config SAP S4, LIMS, DMS
SW 5 Custon applications Custom built software Everything else incl. VBA macros or interfaces
Categories are not set in stone, be flexible but have a rationale for your choice.

Oh NO! It's a V!

Who's afraid of the big V?

  • The V model of GAMP 5 deals with the GAMP process, not the development process
  • V should not strictly be seen as a temporal model
  • You can specify components on the go while developing (yay, agile!)

Waterfall! It doesn't get better!

Design Control Process

Design Control Nomenclature

Input Physical and perf. requirements
Output Results of design effort at each design phase
Review Documented, comprehensive, systematic examination of a design
Verification Confirmation by examination that spec. requirements have been fulfilled
Validation Confirmation by exam. that spec. requ. have been fulfilled for spec. use

Practical Approach

So what do we do?

  • Agile development in a regulated environment?
  • Categorize hardware/software in GAMP category
  • Requirements management (can be partially deferred)
  • Risk management over the whole process (FMEA e.g.)
  • Quality management
  • Development itself
  • Traceability over the whole process

Agile development in a regulated environment?

  • Assess that you have the right people in the team
  • Assess that the organization is willing to adapt its processes
  • Start with a minor project
  • Don't choose the most pressing important project
  • Expand experience, knowledge and acceptance

Obstacles on the way to agile development

  • The auditors/validators are not the problem
  • The standards are not the problem
  • Middle management adhering to established processes is
  • Pay attention to systems theory!

Requirements management


Standard procedure, will not go into details.

Risk Management 1

Risk Management 2

How to do risk management
  • Build a risk register
  • Assess each risk using a matrix
  • Find & apply mitigations
  • Assess mitigation & result

Risk Register Overview

  • There's specialized software
  • There are plugins for tools like Jira
  • In its simplest form two tables for risks and mitigations
  • It's an n:m relation - several risks can have the same mitigation(s) and one risk can have several mitigations

Risk Register Table

Possible columns:
  • Risk ID
  • Description
  • Knowledgeable persons
  • Topic (project risk, technical risk, business risk)
  • Consequence, likelihood & rating of risk
  • Link to mitigation (mitigation ID)
  • Consequence, likelihood & rating after mitigation

Mitigation Table

Possible columns:
  • Mitigation ID
  • Description of mitigation
  • Ticket number in tracker
  • Mitigation owner
  • State of implementation

Traceability Matrix

Possible columns:
  • User Specification ID
  • Design Specification ID
  • Risk ID (not every row will a risk associated)
  • Installation Specification ID
  • Operation Qualification ID
  • Performance Qualification ID
  • Requirement satisfied?
  • Rationale / Mitigation

Change Management


Standard procedure, will not go into details.

Thank you!

Questions or Additions?

References