What master data is and how it differs from other records
A job, person or machine retains its identity while accumulating activity. Its master data describes that identity: code, name, location, status and relationships. A machine inspection or a person’s attendance at a course are associated activity records.
Data quality assesses whether information supports decision-making. Master data management specifies who defines and maintains shared entities. It does not necessarily require a dedicated application: it starts with agreeing identifiers and responsibilities respected by all systems.
Which entities to define
The model must reflect actual work without turning every data item into a separate catalogue. A useful starting point is to distinguish:
- People: internal identifier, organisational affiliation and active dates.
- Jobs and tasks: common name, activities and relationship with risks and preventive needs.
- Companies and sites: structure, locations and responsible personnel.
- Equipment: individual identification, type, location and status.
A person may work at several sites and perform different tasks. Those relationships need dates; a single “current job” field cannot by itself reconstruct a past exposure.
Who maintains each item and how discrepancies are resolved
A reference source and responsible person or function are designated for each entity. HR may maintain starters and leavers; prevention validates the relationship between tasks and risks; maintenance identifies equipment. This is an organisational decision, not a universal rule.
Before integrating applications, document which system may create or change each field and what happens when systems disagree. Do not automatically synchronise two contradictory values. Record the issue, decide which is correct and retain the source and date of correction. Fast synchronisation can also spread an error quickly.
How to implement a shared catalogue
- Inventory current sources and the uses of each data item.
- Define a stable code, name and necessary fields for each entity.
- Identify duplicates and map old codes to new ones.
- Validate relationships with responsible personnel who know the sites.
- Test starters, leavers, job changes and transfers before the full import.
- Monitor integration errors and establish who resolves them.
Measuring duplicates, records without a site or pending changes is more useful than counting completed fields without knowing their purpose. Pay particular attention to exceptions: temporary staff, contractors, shared equipment and people with several roles.
Privacy, history and documentation obligations
The GDPR requires, among other principles, accuracy, data minimisation, security and limited retention of personal data. A shared catalogue does not mean everyone can access everything. Define role-based permissions and avoid copying diagnoses into the general worker master record.
In Spain, Articles 16 and 23 of the LPRL connect assessment, planning and preventive documentation; they do not mandate a particular master data management product. Article 22 protects personal medical information. Retain the history needed to reconstruct activities, applying the periods and legal basis appropriate to each record.
Hypothetical example: a job change that does not reach prevention
A company has “warehouse operator”, “warehouse assistant” and “logistics assistant” in different applications. A person moves to order picking, but the preventive system retains the previous assignment. Creating another name will not solve the problem: the actual task and its relationship with assessment and training must be identified.
The team agrees a job code, retains mappings and records the change date. It then checks that training assignments and risk information are reviewed correctly. To accept the integration, it also tests a leaver, a transfer and a worker combining tasks. Results are verified against those cases, rather than merely because the import finishes without errors.
