There are three “real” types of configuration we worry about when we get to the testing phase of the project. Let me start by saying that I’m not a validation expert. However, having been part of many projects, I will do my best to illustrate the basics of the three types of configuration that we have in our LIMS, ELN and LES projects.
First, the Misconception
The misconception is that “configuration” does not have programming in it or that the programming we do is minimal. This is absolutely not true. Based on the way that implementations are categorized, 99% of what we do falls under the category of “configuration.”
In past years, I tried to convince people in our industry to stop using this confusing terminology because it’s misleading to customers new to our industry. Having failed that, my latest efforts are to try to get the word out to all customers coming into our industry that “configuration” doesn’t merely mean that you press some buttons.
Granted, there actually are systems that customers can purchase that have no programming at all to them but customers new to our industry don’t know which those are. They don’t know to ask whether programming is required.
Below, I will talk about OQ, which is an Operational Qualification. It checks that something works as it’s supposed to. It’s a term used in the validated end of our world. However, even if you aren’t a validated environment, someone still has to do this testing. It won’t have a fancy name but it has to get done, regardless. I use the term OQ to help in the denotation of the level of testing to do but you all have to do it, regulated or not, or your system might not work.
The Three Types of Configuration
- Simple Lists – visual checks. When you put lists into your system and there are no actions associated to them, you probably won’t write a script for it. If you’re merely putting something in like a list of audit prompt phrases, rather than writing a script, it is more likely that you will have someone do a visual check to double-check the spelling.
- Data setup by pressing buttons but with complexity – testing the item. When you create data items such as tests in your system, where you might have been able to press lots of buttons to set it up but where there are actions associated, you are likely to do more than just have someone visually check it. If you were to write an OQ (Operational Qualification) script, the way you will write this might vary. You might want to at least list all of these items and give input and output information so that you can check that the end result is what was expected. In this case, you might not write much in the way of testing steps but you do probably run through each of these items and record that you have done so. Where some items are copies of others, it is sometimes allowed to have a note that indicates that the copied item does not need retesting, and this varies based on the situation.
- True programming – actual OQ scripts. Once, again, whether or not you’re regulated, if you have configuration that requires many, many lines of programming, you have to test it. In the regulated world, this is where you almost certainly write an OQ script that has many steps in it. In the non-regulated world, you still have to test all these steps but it just might not be recorded. The point is this – in systems that require programming for implementation, whether they have you use their proprietery programming tools, such as LIMS Basic or VGL, or whether you use something like C# or Java, you still have to test it. It’s still programming. We can argue about whether we should call it “configuration” or not but when you write code, you have to test it.*
* Some would argue that much of the code in these systems is just one line of code meant to fill a field and that that doesn’t need to be testing. That might be true. However, that is usually such a tiny portion of all the code in these systems that I think it’s grossly ridiculous to bring it up as if it’s the main issue.