Finding the current MDN and MDS codes list sounds like a lookup task. It isn't. A reference code list that's been copied forward from version to version, edited in place rather than rebuilt, quietly accumulates outdated entries that nobody notices until they cause a problem downstream.
Copied forward is not the same as current
The easiest way to update a reference code list is to open the last version and change what looks wrong. That approach only catches the errors someone happens to notice. It doesn't catch codes that were correct last time and have since changed, because nothing prompts a check against the actual current authoritative source.
- Comparing the existing code list against the current regulation or process in practice
- Identifying discrepancies between the old list and the current source
- Correcting outdated entries against the authoritative source
- Confirming the rebuilt list against the source document or QMS procedure
The cost of an unrebuilt list
An outdated checklist or work instruction being followed after the underlying regulation or process has changed is a familiar failure mode, and a stale reference code list is just that failure mode in a different shape. The list looks authoritative right up until someone relies on an entry that's no longer correct.
Rebuild, don't patch
Rebuilding the reference code list from the current authoritative source, rather than patching the last version, corrected the outdated entries and gave the team a list that actually reflects current regulation, not last year's regulation with a few edits.
The Real Takeaway
A reference code list is only trustworthy if it's rebuilt from the current authoritative source each time, not carried forward from the last version.
Patching an old list feels faster, but it leaves exactly the kind of gap an audit or a downstream process failure will eventually expose.