Software validation of Data Exporter

[pmg76]

Hi All,

I'm working on performing software validation as described in ISO 13485:2016 for a "Data Exporter" that generates a Risk Summary Document.

We store our Risk Analysis in a "ticket-like" application. Every Risk Analysis is stored in a separate ticket and contains all required information and justifications.
To generate the Risk Summary Document where we also evaluate the Residual Risk, we use a "Data Exporter" software that collects part of the Risk Analysis information. The generated document is then sent for reviewing and finally approval.

My questions are:
1) Do we need to validate this software? (I assume that this is YES, however I would like to know why do I need to validate a software that generates a document that is afterwards reviewed by a real person)
2) As storing information into data system is very common nowadays, then there must be examples related to "Data Exporter" software. Do you know where can I find this kind of examples?
3) One of the biggest risks for this software is data corruption due to software bug. However this is part of the software verification process. Do we need to consider this as a risk or not?

Let me know if my explanation is not clear enough...

 

[yodon]

You need to have a risk-based means to determine whether and to what extent you validate. Based on just what you said, I would hesitate to say that the 100% output review would be a justifiable reason to not validate. What if the software completely lost a record?

I always recommend:
* Create a Master Validation Plan (MVP) that establishes a risk-based approach to validation decisions
* Compile (and maintain) your inventory of software that you use in execution of the quality system
* Use the risk-based approach defined in your MVP to drive the decision to validate or not and to drive the rigor of validation if validation is, indeed required

Bear in mind that having a system validated is not a one-time event. If you ever make updates to the software, that can (likely) take it out of the validated state and you'd need to re-validate. Other things may also change (support software, network, underlying OS, etc.). A system needs to be established to monitor all this and determine if re-validation is required. (Again, the frequency of such reviews would be risk-driven).

I'm a little unclear what you mean in your 3rd item by "this is part of the software verification process." Can you clarify that?

 

[pmg76]

Hi!

Sorry for the delay! and Thanks a lot for your answer!

1) The lost of records is one of the possible risks that we evaluated.
To clarify more: The "ticket-like" application can list all risks for a particular product and provides a total count. The "Data Exporter" also provides a total count. These two values must be equal and they can easily be verified by the reviewer of the document. However, the reviewer needs "Training" to check this point every time a new risk summary is released. Would this be an appropriate control measure in this case?
Another alternative would be to introduce a verification process in the Data Exporter application. For example, check the same total count in the "ticket-like" application. But then this new process would most likely introduce a new risk. Where do we stop?

2)

Bear in mind that having a system validated is not a one-time event.

Not at all. This is the reason I want to perform automatic validation using a kind-of unit test approach.

3)

I'm a little unclear what you mean in your 3rd item by "this is part of the software verification process." Can you clarify that?

As this is a software then it will have bugs. These bugs may introduce data corruption in the exported information (for example: one of the risks has an evaluation of "Unacceptable" but the tool export it as "Acceptable" due to a bug). I'm assuming this kind of bugs will be eliminated during the verification process (we use a "standard" software development process).
In spite of my naive assumption there is still the possibility that bugs can create data corruption, do we need to evaluate the risk that a bug in the application will corrupt the exported data?

 

[yodon]

Not at all. This is the reason I want to perform automatic validation using a kind-of unit test approach.

Strictly speaking, unit testing is low-level testing not generally performed in validation. Automated testing is a generally done at the system level. I may be just quibbling over terminology.

I'm assuming this kind of bugs will be eliminated during the verification process (we use a "standard" software development process).

Bugs can't be eliminated in verification, they can only be revealed. Use of a rigorous development process only reduces the likelihood of error introduction.

In spite of my naive assumption there is still the possibility that bugs can create data corruption, do we need to evaluate the risk that a bug in the application will corrupt the exported data?

Sure, no software is completely bug-free. Yes, you should evaluate the risk and if the consequences of failure (data corruption) are sufficiently high and the current controls cannot bring that down, you may indeed need to consider other types of controls - which could include manual, independent inspection of the output.