Updated: Sep 14
In some ways, almost everybody met the term 'master data' (only for my Hungarian fellows: törzsadat :) ). It's used not exclusively in pharma, but people working with either LIMS or any ERP modules may be more familiar with the concept of it.
And still, no authorities' data integrity guidelines consider this data type as special.
Why? - I don't have the answer for it :)
But how can we create a compliant environment for all our master data? this is the question we seek the answer for.
I think this topic will win a series of posts, but let's not get ahead ourselves: first let's try to define master data, and then let's think about the consequences of that definition.
How to define master data
So let me be blunt and offer a definition here (I will admit, I stole a part of it from the non-pharma world):
'set of parameters for system control, and data collection, processing and reporting.'
In other words, we create master data to tell how to control the system how to collect data, and then how to process it.
If you start to think about master data like this, you also will start to feel that there is not much difference between configuration (finally, a term the regulators know :) ) and master data.
How do we have configuration under control? For all computerized systems, we apply the pre- and post-approved OQ to test out the configuration we specified in the FS/DS. For GAMP category 5 systems, we may have to perform a formal code review.
So all in all, this is a bit of an overkill for master data. Or is it?
In LIMS, master data processes raw data to generate the final results for the CoA of your product. In your manufacturing control SCADA, master data drives all the production parameters.
Yeah, let's reconsider if this is really an overkill :)
Master data requirements
What we need, is the appropriate and efficient control on our master data, following the data integrity requirements. As I see, these minimum requirements would be:
- only reviewed/approved master data should be used in GxP data lifecycle
- after review/approval, master data should be protected from alteration
- when applying master data to collect/process/report data, the traceability between master data and generated data should be unambiguous.
And since master data is still considered data:
- the attributibility of the master data should be clear: it should be traceable who compiled it and when, and who reviewed it and when (full audit trail)
And let's think about the separation of different user roles: if we consider master data similar to configuration, should the people with master data editing rights be separated from the users with data generating rights? I think so, but sometimes this is a huge challenge for the departments, and also may be for the systems.
How can we fulfill these requirements? We will come back with some real-life examples a bit later.