Computer Software Validation

ISO 13485:2016 is finally here!

On March 3rd, the 2016 revision of ISO 13485 was finally released. The new revision is essentially an evolution of the 2003 revision and includes a number of changes and clarifications.

For Aligned Elements users, a change in section 4.1.6 might have some important implications. Whereas ISO 13485:2003 did not explicitly require computer systems used in the quality management system to be validated, the 2016 edition certainly does. ISO 13485 is now finally on par with FDA 21 CFR 820 on this matter.

csv

Computer Software Validation is used to ensure that each computer systems fulfills their intended purpose. It prevents problems with the software to reach the production environment. CSV is today used in many regulated industries and is today regarded as a good manufacturing practice.
Aligned Elements certainly fall into the category of Computer systems that must be validated according to ISO 13485:2016 and FDA 21 CFR 820. If you do not have CSV process in place, we do have some things that may help you.

Why is Aligned Elements not validated by Aligned AG?

Aligned Elements falls into the GAMP 5 Software category 4 - "Configurable Software". AE is a highly configurable software with the purpose of mapping the customers QMS, as opposed to force the customer to change his processes and templates to match Aligned Elements.
When validating a software of Category 4, it is of course the particular configuration of the software that is validated. Since each Aligned Elements customer is using a different configuration (each customer has its individual QMS), we cannot forsees which configuration our customers will use.
As mentioned, we do supply a number of useful tools to make the validation process faster.

What do I need in order to validate Aligned Elements?

Even though ISO 13485:2016 and FDA 21 CFR 820 require Computer Systems used in the Quality Management System to be validated, they do not explicitly described how to do it. This is up to each organisation to decide.
With no intention to be a complete listing, you need at least the following things:

  1. A Standard Operating Proceedure (SOP) that describes how Computer Software is validated in your organisation
  2. A validation plan, that describes:
    • INTENDED USE of the computer system in question
    • WHAT are you validating, i.e. which name, version and configuration of the software including manuals and supplier information and target environment
    • WHY are you validating this software to this particular extent (hint: the GMP Software Categories are a good starting place. A risk-based approach is also viable starting point.)
    • WHO is responsible for the software, for the maintenance of the software and who is responsible for the validation
    • HOW do you intend to validated the software, what the acceptance criteria is and in particular how do you intend to handle software errors detected during the validation
    • DELIVERABLES i.e. the documentation you intend to provide
  3. Requirements and/or use cases describing how you intend to use the Computer Software.
  4. Tests verifying that the use cases and documenting any deviations found.
  5. A Validation Summary or Report stating the result of the validation, preferably with some kind of traceability and weather the Computer Software should be cleared for use in the production environment

To make this process a bit simpler, we provide our customers with a pre-filled example validation kit of Aligned Elements that can be adapted to the individual needs of each organization.

Can Aligned Elements be used to document the validation of other systems?

Absolutely. Aligned Elements is very well equipped for documenting the validation of other systems (provided AE has been validated, of course). AE supports all steps of the CSV process, from evaluating the validation extent via checklists or using a risk based approach, documenting requirements, use cases and test cases, executing test cases, analysing the test results and finally supplying the necessary traceability reports.

Learn more about how Aligned Elements can help with achieving regulatory compliance

Request a live demo and let us show you how Aligned Elements can manage your documentation

Medical Device Validation: what is it? Wait! Are there several kinds?

"Validation" is one of those terms that can be confusing for people new to medical device development.

This word, "validation",  is used in (at least) three different contexts that are not necessarily related.

These are:

  • Design Validation
  • Process Validation
  • Computer Software / System Validation

Let's take a look at each one of these in turn.

Design Validation

What is it?

The regulatory lingo (in this example from FDA 21 CFR 820.3) for "Design Validation" declares that it is about “establishing by objective evidence that device specifications conform with user needs and intended use(s).”

It is a mandatory step in the medical device development process and if you are developing a medical device you will have to perform it at some point.

Why is it done?

Design Validation is about proving that we have "built the right thing". This is often contrasted with Design Verification which is meant to prove that we "built the thing right".

The difference lies in that the latter checks that the device was designed/built according to specifications (which is very important), whereas the former checks that the device works as it is intended to work for the end user, where the intention is documented in the User Needs and to some extent in the intended use.

As you can see, there regulations have foreseen that there might be a discrepancy between the intention and the specifications derived from the intention when developing the device.

It might be the case that the designers have not solved the user needs in a way that makes the device usable.

"Anecdata" provides endless examples of devices that are built "correctly" according to specs but turns out to be unusable / dangerous when used by the end users in a real environment e.g. a glucose monitor alarm is not loud enough to be heard when travelling on a noisy bus.

Does this all sound like "usability" and "human factor analysis" activities to you? Then you are exactly right. Design Validation bears many similarities with usability activities. However, Design Validation also includes clinical tests in order to establish that clinical results corresponds to expected levels are under intended use.

What is the input for the activity?

How do you know what to validate? Simply put, your User Needs. Therefore, it is important to define the User Needs in a manner that makes them possible to validate in a practical way.

Hence, the next time you write down your User Need, think hard about how you plan to validate them.

When is it done?

Design Validation is usually performed at the end of the design process, often after the Design Verification has been completed but before the medical device is transferred to production.

The instances of your medical device used in the validation should ideally exist in production-equivalent state.

Who is involved?

The Design Validation tests are generally performed by real users (doctors, nurses, patients etc.), preferably in the actual intended environment (in the hospital, in the lab, in the ambulance, at home etc.). The idea is to get as close as possible to "real use by real users".

Engaging this type of personnel can be both complicated and costly. It is therefore important to plan ahead and secure necessary resources (location, personnel etc.) well in advance.

If the validation reveals serious flaws in the device, which requires re-design, sever consequences on development time-lines and costs are at stake.

It is therefore important to involve real users throughout the design process and not only at the end.

How is it documented?

Like all other Design Control stages, the Design Validation needs to be planned, which is documented in a Design Validation Plan, and then executed, which is often documented in validation test cases and results. The summary and outcome is documented in the Design Validation Report.

Traceability, consistency and completion are of course important steps at this stage. Therefore, Aligned Elements is a great tool to use for these activities.

Process Validation / Production Validation

What is it?

Process Validation most often means validation of your manufacturing process or parts thereof (although many other processes can be subject of this validation as well).

Or in FDA lingo, "process validation means establishing by objective evidence that a process consistently produces a result or product meeting its predetermined specifications."

Why is it done?

So why is this important? FDA requires (21 CFR 820.75) the "results of the process" ("results" = your medical device, "process" = your manufacturing process) to be "fully verified by subsequent inspection and test".

This is a way to say that each unit of your produced medical device must undergo "full" final testing and inspection and thereby we ensure that this particular instance of the medical device is safe for the user to use.

Now, there are cases when it is not possible to verify a safety relevant characteristic of the device using testing and inspections, with the typical example of sterile devices as prime contender.

To verify a device being sterile, one would need to break the sterilization barrier (open the packaging) which would of course make the device non-sterile and therefore unusable/unsellable.

So when it is not possible to "fully" inspect and test the device, you can resort to process validation.

Thus, you employ process validation to check that the production process gives your medical device that particular, safety relevant characteristic every time for every device.

What is the input for the activity?

Although ISO 13485 and FDA QSR 820:75 both lists process validation as something very important, they are both a bit elusive on exactly which parts to validate. Basically, all the characteristics that cannot be fully covered in the final inspection are eligible to process validation.

For more information, the go-to document for Process Validation, although published in 2004, is the GHTF SG 3 NB 99:10:2004.

When is it done?

Generally, process validation is a pre-production activity, meaning that the production line is fully operational but you have not yet started production "for real".

Who is involved?

Just like for Computer Software Validation, the legal manufacturer is the responsible party. However, it is not uncommon to outsource parts of the work 3rd party supplier or OEM manufacturers. 

How is it documented?

The "GHTF SG 3 NB 99:10:2004" goes a long way in describing the recommended documents. Very broadly speaking, there ought to be a Process Validation Plan, sections describing IQ, OQ and PQ activities, and finally a Process Validation Report.

 FDA explicitly requires the following from the validation, which ought to be properly documented:

  • All activities which have been carried out must be recorded, including date and signature.
  • Procedures, with which process parameters are shrivelled, must be established.
  • Only qualified personnel may validate a process.
  • Methods and data used for controlling and monitoring processes, the date of execution, persons carrying out the validation, as well as relevant equipment must be documented.
  • In case of changes, the manufacturer must assess whether re-validation is necessary and must carry it out if needed.

Computer Software / System Validation

What is it?

This type of validation, often shortened as "CSV", concerns "data processing systems are used as part of production or the quality system" (from FDA QSR 820.70) or, as freely interpreted from ISO 13485:2016, all computerized systems being used in any of the processes regulated by the QM system.

Thus, it does not concern the software in your device. Rather it refers to computer systems used to design and produce your medical device. Aligned Elements is an example of such a system. Other examples include Excel Spreadsheets, e-QMS systems, measuring equipment in production and so forth.

Why is it done?

A multitude of regulations (FDA 820, FDA CFR 20 Part 11, ISO 13485, GAMP5) recognizes that patients/users are potentially exposed to safety risks if the computer systems employed in the design and production process of the device does not behave as intended.

Computer Software Validation is the suggested remedy to this perceived risk.

What is the input for the activity?

The input for the CSV is the User Requirements that should, as one might thing, specify what the software under test can do, but rather what the organization plans/intends/want to do with it.

If you plan to use Excel for calculating a tolerance, then you the User Requirement should state exactly that.

It is recommended to take a risk-based approach to the testing and focus on the User Requirements that render the most severe risk impact if not adequately fulfilled.

So what about the validation of the software used in your device? Since you are then validating the design of your device, go check the Design Validation section. 

When is it done?

CSV should be performed on the target computer system before it is put in use.

Who is involved?

The responsible party getting the CSV activities planned and executed is clearly the organization that uses the computer system. However, the actual leg work is sometimes outsourced to 3rd party suppliers. Note that it is not mandatory for end users to be involved in the actual testing.

How is it documented?

How the organization performs CSV shall be defined in an a company SOP. The SOP shall define which computer system types that falls under CSV, how to plan and execute the CSV activities, and under which criteria a re-validation is applicable.

In its most basic form, a CSV plan should state the User Requirements which captures the intended use of the systems. The User Requirements are then tested in IQ, OQ and PQs and the results of these tests and, if applicable, deviations are summarized in the Validation Report.

Conclusion

As we can see, although these three types of Validation do not have a lot to do with each other, they are very important to Medical Device manufacturers.

A common trait for all activity groups is that they need be properly documented, often following the same type of scheme, starting out with a plan document stipulating the "things to check for" (requirements), a number of test protocols to be executed, collection of objective evidence, traceability and report generation.

Aligned Elements is a perfect tool to structure and manage these type of validation activities and manufacturers can therefore benefit from Aligned Elements in all tree areas.

For a free trial of Aligned Elements, start here.   

Speed up your Computer Software Validation activities

Computer Software Validation is something we discuss a lot where I work. Since Aligned Elements is a Medical Device Quality Management System relevant software, our customers make sure that their Aligned Elements installations and configurations are validated.

It is a necessary activity, although not always perceived as bringing an awful lot of value. Sometimes the cost of CSV activities actually supersedes the cost of acquiring the software itself. 

I sometimes get the question if I know any best practices when it comes to Computer Software Validation and I have made a few observations from my CSV experiences. 

Let me tell you about the top 3 things that has an impact on the Computer Software Validation effort:

1) How many test cases do you perform?

It is dead simple. More test cases (note: not necessarily "more requirements") is more work. But do YOU have to perform all those test cases? What if the supplier has already verified them? 

You are very much allowed to leverage existing supplier documentation and testing records. A properly conducted Supplier / Vendor assessment can lead you to the conclusion that the suppliers verification documentation suffice. Remember that the risk we are trying to mitigate with a Computer Software Validation effort is primarily about patient safety. A software like Aligned Elements is not directly involved in the patient safety and this fact can be leveraged when assessing and deciding on the validation scope. 

2) How do you record the test results?

The bulk of the CSV work resides in performing and recording the test results. The way you record those results can have a significant impact on the overall effort. In order to record that the actual behavior of a test step corresponds to the expected behavior, is it enough to tick a box (passed/failed)? Or do you need to write a text? Or do you need to make screenshots? As you can imagine, there is a huge difference between the former and the latter.

"But are we not required to take screen shots?".  The short answer is "No, you don't". Not if you do not think it proves anything more than the tester checking a box. FDA requires you to select your own methods and tools for quality assurance. If you have a good case for not making screen shots (which I think you have), you do not have to.

3) Who (and how many) has to sign all these CSV documents?

This might sound a bit odd but more than once I have run into cases where the validation is completed and everything that is missing is a signature from some top management figure. And now we run into a buy-in problem. If this guy has not been involved CSV approach and suddenly disagrees with how it was conducted ("BUT THERE ARE NO SCREENSHOTS?!?"), it can have a significant impact (significant as in "redo the validation").

So the lesson here is to get early buy-in from the people that sign the document. On a general level, reducing the number of signatures will speed up any documentation process. And you might want to contemplate on the necessity of having the IQ, OQ and PQ plans / reports in different documents (more documents to sign) or if you can combine them.

Validating Aligned Elements

When you acquire Aligned Elements, you get free access to our internal verification documents to use in your vendor assessments as well as pre-filled Validation documents to kick-start your validation. Contact us for more information on This email address is being protected from spambots. You need JavaScript enabled to view it.

What's up ahead regarding Computer Software Validation?

FDA announced that their much anticipated "Computer Software Assurance for Manufacturing, Operations, and Quality System Software" draft guidance should be out in 2019 but now it seems like it has been postponed to 2020. The new guidance is supposed to use a more agile approach, including a risk-based and value creating perspective on CSV activities.