- Published
- Updated
A mapping table may control site codes, test names or product descriptions. A one-row change can alter the interpretation of thousands of records, so a table’s simple appearance does not guarantee low operational risk.
Preserve the meaning of data
Define who can propose a master-data change, who verifies its meaning and how the active version is recognised. A technically unique key does not prove a scientifically or operationally correct match. Make effective dates and retrospective application decisions explicit. Link the relevant mapping source and change rationale to the controlled version used in processing.
Worked example
For example, two similar laboratory tests map to one target code although one represents a different specimen type. An expert reviews the table’s meaning rather than code format alone. After correction, the team identifies records processed under the earlier version and assesses reprocessing needs. Loading a revised table does not automatically repair historical mappings.
Review checks
- Sample similar-looking codes that represent different meanings.
- Review a proposed change together with the population it affects.
- Link the mapping-table version to each relevant job or delivery.
Acceptance and boundaries
Acceptance means a selected record can be explained through its approved mapping rule. Not all master data need the same approval layers; choose according to impact. An expedited correction route still needs truthful authority and control evidence. For frequently changing tables, reviewing differences may be more useful than rereading the entire file, while meaning verification still requires responsible expertise.
Frequently asked questions
- Is checking for duplicate keys sufficient?
- No. A unique but incorrect mapping can still distort meaning.
- Must historical records be reprocessed after every change?
- Assess scope and purpose, documenting the rationale for any retrospective application.