Developing Custom Software in a Regulated Environment

21 CFR Part 11 / Computer System Validation

Tier 2 has significant experience of implementing systems to comply with the FDA’s 21 CFR Part 11, of which Computer System Validation (CSV) is one key part.  ‘Computer System Validation’, in summary is the documented process of ensuring that a system does what it is designed to do, in a consistent and reproducible manner.

In addition to Standard Operating Procedures (SOPs) addressing, for example, the IT infrastructure, there are a number of important Part 11 considerations relating to the design, development and implementation of custom software:

  • The systems development lifecycle approach
  • The level and type of documentation produced (including, but not limited to, detailed requirements documentation and test plans)
  • Specific features which must be included in the custom software (such as audit trails, electronic signatures, and security features)

Agile Software Development

scrumTier 2’s standard project delivery approach is based on ‘Scrum’, which is an agile methodology. By ‘agile’, we mean an approach based on iterative and incremental development, where requirements and solutions evolve through collaboration between cross-functional teams.

It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. Scrum provides a balance between functional flexibility (the ability for users to adapt or add new requirements as they see the solution evolving), and cost control.

Agile in a Regulated Environment

Tier 2 understands and has first-hand experience of developing applications, and the associated documentation, which must comply with regulatory standards, and which has been “validated”.

Thankfully it is not as commonly held a view as several years ago, but some project ‘traditionalists’ have voiced concerns that agile processes are undisciplined, and therefore incompatible with quality management – but the reality is that this is some way from the truth.

The standard disciplines of planning, requirements definition, design and testing are all part of the agile process – a difference being that agile repeats itself in smaller increments. The process is designed to get feedback throughout the course of the development project, and use this feedback to continuously improve the product.

The agile feedback loop can be adapted/extended to accommodate specific regulatory requirements (e.g. risk management, validation, regulatory documentation etc.).

For further information about using agile in a regulated environment, please see the following link:

Open Source in a Regulated Environment

The use of open source software in regulated environments is now commonplace, thanks in no small amount to companies like Red Hat – who provide enterprise-class support and maintenance services to rival, and in many cases exceed, that of traditionally licensed software.

Developers and technical architects have long since been supporters of open source – because the community development model drives innovation and open standards, and a roadmap defined by users of the software, and not the proprietary software vendors.

Red Hat JBoss Middleware provides companies with the best of both worlds – all the benefits of open source software, with the added assurance of cost-effect support and maintenance services backed by defined SLAs.

As used by GlaxoSmithKline

Tier 2 has designed, developed, supported and maintained a range of applications for GlaxoSmithKline, including Web-based Electronic Document Control, and Genetic Toxicology Tracking (“GETIT”).

Key aspects of these projects included:

  • Systems were implemented to include the system features required by the FDA’s 21 CFR Part 11 (e.g. electronic records & signatures, audit trails).
  • The document control solution was itself validated, with Tier 2 contributing to much of the required documentation (for example, requirements definition and IQ documents).
  • The design and development of the genetic toxicology tracking system required tight integration with pharma-specific technologies – for example molecular substructure searching, and Lhasa’s deductive risk database.

View the GSK “GETIT” Case Study