21 CFR Part 11 and the SDLC

In this posting, I will attempt to address the challenges posed by the FDA 21 CFR Part 11, which is a law aimed at ensuring that companies implement good business practices, in their developing software efforts to meet said requirements.

Background Definitions

21 CFR Part 11

Title 21 is the portion of the Code of Federal Regulations (CFR) that governs food and drugs within the United States for the Food and Drug Administration (FDA), the Drug Enforcement Administration (DEA), and the Office of National Drug Control Policy (ONDCP).

21 CFR Part 11 addresses Standard Operating Procedures (SOPs), Medical Device Quality Standards Regulation (QSR), Good Clinical Practices and Good Manufacturing Practices.

SDLC

The systems life cycle (SLC) is a methodology used to describe the process for building information systems.

The Systems development life cycle (SDLC) is a process used by a systems analyst to develop an information system, training, and user (stakeholder) ownership. The SDLC aims to produce a high quality system that meets or exceeds customer expectations, reaches completion within times and cost estimates, works effectively and efficiently in the current and planned Information Technology infrastructure, and is inexpensive to maintain and cost-effective to enhance.

Following a SLDC in order to develop a 21 CFR Part 11 regulated software application is essential because its very intent is to provide a very deliberate, structured and methodical way, reiterating each stage of the life cycle. The SDLC describes the different stages involved in the software development project from the drawing board/planning, implementation, testing, deployment, through the completion of the project.

Project managers benefit from the process, tools and project artifacts generated as a result of following an SDLC. The project life cycle integrates the project management and SDLC cycles with the activities directly associated with system deployment and operation.

The Hurtle

The FDA recommends that application development teams take an integrated approach to their software development lifecycle (SDLC), which combines risk management strategies with principles for software validation.

But developing software for medical devices that complies with the FDA's Quality System regulation is necessary hurtle for companies that want to compete in the medical/FDA-regulated industry.

This hurtle is not near as "complicated" as some make it seem.

It basically means that your software needs to be engineered properly with complete access control and audit capabilities.

Experience Matters

Since I have well over 10 years of enterprise application security software development experience and have worked with some of the most talented software engineers in the world, these requirements seem easy/natural to me.

I enjoyed over 10 years of hard core software application development prior to joining IBM.

In my first project at IBM, I researched and developed security components for SmartCard LifeCycle Management System using IBM's flagship e-business security software, Tivoli Policy Director (TPD), which allows organizations to create secure relationships among customers, partners, suppliers and employees.

I focused on enterprise-security-related software application development projects, such as:

• Software Engineer I architected and implemented various design patterns for Web Identity (formerly IBM Registration) is the standard service for IBM external applications that register, authenticate, or profile external web-based customers, business partners, suppliers, and other users of ibm.com. WI performs Single Sign On, Global Session Persistence, and User Identity and Profiling and Access Control functions.
• Security Consultant Implemented IBM.COM Single Sign On (SSO) prototype for IBM’s BT/CIO office and the Tivoli PDT.
• Security Architect & Lead Developer Designed and implemented Voice over IP (VoIP) security architecture for a fortune 5 telecommunications company. System components (order entry, billing and account management ) were presented to users (customer facing and a customer service rep (CSR)) via web based portal application. Designed corporate messaging infrastructure to manage application entitlements (user creation and role management).
• Lead Security Application Developer Performed analysis, design and implementation phase of enterprise Authentication and Authorization infrastructure replacement project for fortune 5 financial corporation.
• SOA Security Architect Produced detailed SOA Security Architecture deliverable for Service Oriented Architecture Methodology (SOMA) engagement focused on contract, pricing and rebate functionality for a distributor of medical products, equipment, billing services and pharmaceuticals.

I later transferred from IBM Global Business Services to the IBM Software group to help develop the administrative UI for the IBM Next Generation Intrusion Protection Appliance.

Software Development Methodologies

Waterfall Methodology

Early in my programming career, I worked for several fortune 500 companies that followed the Waterfall software development methodology:

What always happened on those projects was the business analysts would take in inordinate amount of time to fully define everything about the system, even though none of them had any relevant software development experience, and produced a tome of a design document, which was supposed to serve as a reference for developers' requirements.

At that point, the project was always behind schedule and my team took over.

I would spend a day or two reading through that wordy tome and make my own (useful) design documents.

Next, I would find the subject matter experts (SMEs) to validate my designs and begin a series of design/implement/evaluate sessions, very much like the Agile process, but light on testing. (The need for testing, especially in a team environment that uses a constant integration (CI) server is a topic for another day :-)

The fact was that the project management office would be freaking out as the customer began to tighten the rope of leniency as they began to get concerned that the project was falling behind since they had not "seen" anything.

Process and methodology at that moment was always thrown out the door as the project manager (PM) would scream, "Just get 'er done."

Rational Unified Process

Prior to joining IBM I worked at an internet consulting company iXL where we followed the Rational Unified Process (RUP) of software development.

The purpose of following RUP software engineering methodology is to provide a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget. RUP is “use-case driven, architecture-centric, and incremental and iterative”.

RUP Phases

Here's a high level view of what the RUP phases:

Here's what a typical RUP plan would look like:

Objectives

• Improve the integrity of the commitments made by SDLC by defining the business process by which decisions are made.
• Minimize product changes (churn) once the decision is made to initiate a project.
• Define a common framework for communicating project status in terms of business commitments
• Enforce appropriate minimum standards on entry and exit criteria for each applicable project lifecycle phase.
• Define milestones for project process metrics: Cycle Time & Quality

RUP was a big improvement over the Waterfall methodology, but many software development projects would still fall behind schedule, leaving PM's standing in the lurch. Then, along came Agile...

Agile software development

In 2001, the Agile software development methodology became popular, which is based on the Agile Manifesto:

We are uncovering better ways of developing software by doing it and 
helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, 
we value the items on the left more.

Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

Agile provides well-defined planning events and a "time-boxed", iterative approach to development that project managers like.

The trouble with many Agile projects is that the focus is on cranking out stories (aka Use Cases in RUP parlance) and their associated features with less emphasis on code quality.

However, the 21 CFR Part 11 and the FDA, in general, is all about quality...

... and that's a problem.

Some Software requirements for 21 CFR Part 11

• System validation to make sure performance of the system is accurate and reliable.
• System should be able to produce accurate/complete record copies that are readable both in human and electronic forms.
• Record protection to ensure they are accurate and able to be retrieved easily.
• System access should have strong controls to prevent unauthorized access.
• Must have time stamped audit trails.
• Operational system checks must be in place to ensure proper sequencing of steps and events.
• Authority checks must be in place to make sure that only the authorized personnel can get into the system.
• Proper controls on system documentation
• Complete and accurate record retention practices
• Written policies must be produced that hold everyone accountable for any actions via their electronic signature.

Other Systems Impacted By 21 CFR Part 11 Requirements

• Employee Training
• Document Management
• Change Control

Out of Compliance

If you get audited and found wanting, you will get a 483 (FDA violation) citation.

A 483 is issued when investigators observe any significant objectionable conditions. FDA investigators are trained to ensure that each observation noted on the 483 is clear, specific and significant. The observations are cited when in an investigator’s judgment these conditions or practices observed indicate that an FDA-regulated target is in violation of FDA’s requirements.

Example 483 violations

http://www.fda.gov/Food/RecallsOutbreaksEmergencies/Outbreaks/ucm224855.htm
http://www.fda.gov/AboutFDA/CentersOffices/OfficeofGlobalRegulatoryOperationsandPolicy/ORA/ORAElectronicReadingRoom/ucm061813.htm
http://www.fda.gov/downloads/ICECI/EnforcementActions/WarningLetters/1999/UCM067262.pdf
http://www.fda.gov/ICECI/EnforcementActions/WarningLetters/2005/ucm075385.htm

I think it's safe to say that no business owner would ever want to receive one of those.

Summary

All projects need to be performed and delivered under certain constraints. Traditionally, these constraints have been listed as "scope," "time," and "cost". These are also referred to as the "Project Management Triangle". You cannot change any one constraint without affecting the other two.

These three constraints are often competing constraints: increased scope typically means increased time and increased cost, a tight time constraint could mean increased costs and reduced scope, and a tight budget could mean increased time and reduced scope.

Quality is of utmost importance in projects that intend to meet 21 CFR Part 11 requirements.

Therefore, unless the technical resources that implement the application care a lot about the quality of their code, are seasoned enough to understand what good code means, and are willing to enforce coding standards and stand up to PM's that are always pushing to "get 'er done", the risk of delivering software that complies with FDA regulations will always exceed an acceptable level, regardless of the chosen software development methodology (and some form of agile is the way to go).