--------------
In a previous post, we tried to define master data, and collect the requirements to it.
Now let's try to go through some examples, and let's start with the more simple one.
Example 1: standalone pH meter with a printer
Let's go through our system: we have a firmware that controls pre-defined calibration method, some configuration to tell when the equilibrium is reached on pH and temperature, (maybe) paper-based report content parameters, (hopefully) user and (undoubtedly) user level management, and date and time management.
So all in all, we have a LOT of configuration and master data to be dealt with here.
But still, it's considered a relatively simple system, so let's try to solve the master data problems with simple solutions.
Let's go through the 2 types of data generated:
Calibration, daily check
as I see, this could be handled with a two-step solution:
- it can be only changed by a reduced number of individuals (administrators)
- each time the check is carried out, every used piece of metadata is printed on paper - so when it's signed off, the related master data is approved with the calibration
Test execution
Again, the report can save us here: if we can print all applied master data parameters (or we can have a method ID, and we can print out the method separately), we can solve the approval of master data with the approval of the test results.
Administration
We can be sure now that administrator capabilities are unavoidable there. Not only for updating methods, but to set date and time, or the administer users in the system.
I know this is not the most elegant way of having master data under control, but until we can connect our pH-meter to LIMS, this solution should be considered compliant by the authorities.
Built-in features as potential traps
Sometimes there is a vicious trap in these 'simple' instruments.
Since these instruments already need some kind of electronic driver, it's so easy to add more features to it...for the manufacturer, but not for Pharma process owner. My favorite example is pretty common: they produce these instrument to keep the last 10, 50, etc. results in their memory. Okaay...but if it's stored and retrievable, do 21 CRF Part 11 and EU GMP Annex 11 apply here?? Will I need periodic backup, as an example for my electronic records?
As I see, there are 2 options here:
First option is to try and switch off all of these features that would wake anybody's suspicion that we are dealing with electronic records in our instrument. But if we cannot do that:
The second option is to proceduralize the situation, and also the clear decision what you consider as record in your instrument. If you clearly describe that your printed report is the record that helps you to make your release decision, you are out of the woods.
But we should also never forget that we are in 2023, so the clearest (and also the most efficient for the users) solution is to connect your instrument to LIMS, making the data flow automatic and secure.
תגובות