Blog

Retrospective Validation

by



I don’t even really like to use the word retrospective. I prefer to use the term validation or revalidation. Validation of software and computer systems used to automate regulated activities or record keeping is required for compliance with FDA regulations. In a situation where this has not been performed prior to actual use of the automation, non-compliance with FDA requirements becomes an historical fact and regulatory exposure remains.

Retrospective validation was a term initially used by FDA several decades ago when it first began requiring computer system validation and many systems were already in use without validation procedures or evidence of validation. Special techniques were permitted to retrospectively demonstrate that a computer system works properly. This generally applied to cases where there was independent historical evidence that could be collected and used to show proper operation. An example would be an automated sterilization system used in manufacturing where data from independent logging devices recorded key process variables such as pressure and temperature. This type validation was not intended by FDA to be acceptable practice going forward. The validation requirement was intended to ensure the computer system was proven to work properly for its intended regulated purpose prior to relying on it in production or the quality system. Of course, there are also FDA requirements for design control, verification, and validation of software used in medical devices or as a standalone medical device itself. Continue Reading



How 21 CFR Part 11 Affects V&V

by



All FDA regulations and ​​guidance are available for free online, but this doesn't make interpretation or implementation any easier.

One of the most important aspects of Part 11 is the applicability. Does it apply to your software? Are you dealing with actual product software or quality system/manufacturing software? In certain cases, actual product software may be subject to Part 11 requirements, but more likely it is the quality system/manufacturing software that must comply. If it does apply, one thing is sure - the FDA recommends a "narrow interpretation scope" to prevent unnecessary overhead.

Here are some helpful questions you should ask:Continue Reading



The First Step of Medical Device Software Validation

by



Every journey starts with a single step, and often, it’s hard figuring out what that step should be when you need to validate a medical device to the expectations of FDA. Below are some high-level steps in order to kick-start your validation:

Step One: What standard operating procedures are applicable to the product you are responsible to follow? Are the procedures appropriate for the software requiring validation? Determine what process standards may be required for the medical device development. For example, should the process comply with IEC62304? For software as a medical device (SaMD) products you may want to follow a process that complies with IEC82304? For risk management, ISO14971 is likely applicable. Standards will likely give you confidence in the approach to validation and let you know what is required along the way.

Note: If no policies or procedures exist, then it’s time to create them. Consider writing a ’heavy’ plan that provides process requirements that comply with standards. Continue Reading


Epics, Stories, and the Epic Story of Agile Medical Device Companies

by



A short, short time ago, in this very own galaxy some companies were not making blockbusters, but medical devices. Whispers of quicker development times and better testing made the way past the water cooler until it became time to indulge and implement the mythical software development lifecycle. With the changes came weird language and rumors that the company would now create epic stories and employees would be running very fast around the building (e.g., sprinting).

Spoiler alert: There is no forced exercise, but employees would actually be writing stories and epics.

Conventional waterfall models use versions and products as the development rollercoaster. Someone (hopefully) writes the software requirements, then an exclusive group reviews and approves them. Then came the very difficult task of software design and how it should be documented. And, “what about the architecture – did it ever get copied from the whiteboard into a document?” Next, the software is implemented by “I code – I don’t document” Donnie and when that is almost finished, “do I have to test all that” Connie starts testing the software. Continue Reading


HealthIT and Software as a Medical Device

by



So what if my software for a medical application is "stand-alone”? That is, it simply runs on standard computing platforms - no custom hardware. What safety standards apply or would be useful for ensuring safety? Certainly 62304 provides the basic elements of the software development lifecycle, but 62304 stops at "verification" and purposely does not cover product level validation level aspects. 62304 does require use of a quality system with design validation at the system level and ISO 14971 for device risk management, but 62304 is scoped for medical devices, not HealthIT in general. This leaves a gap for stand-alone medical applications considered Health IT but not a medical device. Continue Reading




Contact Us









T: (813) 766-0563