"MDR" as a task title sounds simple, but closing an open item in an MDR technical file is rarely a general update. It's a tracing exercise: every MDD-era requirement or code that used to justify a claim needs an explicit, defensible MDR equivalent, or the gap sits there until someone comes looking for it.
Mapping, not rewriting
The instinct when facing an open MDR item is to rewrite the section to sound current. That's the wrong move. The actual work is mapping: taking each MDD-era requirement or document, finding its MDR equivalent using the technical documentation correlation tables, and verifying that equivalence against the applicable harmonized standards.
- Mapping each MDD-era requirement/document against its MDR equivalent
- Using the technical documentation correlation tables as the reference
- Verifying each mapping against applicable harmonized standards
- Tracking the action item to closure in the quality plan
Why "general update" isn't good enough
An MDD-era requirement with no confirmed MDR equivalent doesn't disappear just because the surrounding text got refreshed. Left unmapped, it stays in the technical file as an unresolved thread, and a notified body's job is to pull exactly those threads. A traceable mapping, correlation table entry to harmonized standard, closes the loop in a way a general rewrite never does.
Closing the loop
Completing the technical documentation correlation to the applicable international standards closed the open item in the file. What made the closure hold up wasn't the paragraph that got rewritten, it was the traceable line from the old requirement to its new equivalent, checked against the standard that governs it.
The Real Takeaway
MDD-to-MDR transition work only closes cleanly when each old MDD code/requirement is explicitly mapped to its MDR equivalent.
Treating it as a general update instead of a traceable mapping exercise leaves gaps a notified body will find first.