@Tagin is putting you on the right track. But are you JUST interested in the feedback process or, more broadly, production and post-production information to use in managing risk?
The list provided is good. I'd probably add (or at least consider adding):
- product in use description (revision, software version running if applicable, etc.)
- use environment (sometimes asking such questions, you may learn of new use scenarios previously not considered)
- If the feedback was a complaint (and, if so, linkage to any complaint management)
- some way to monitor for trends (e.g., if the feedback is relative to a particular component or aspect)
As an aside, feedback should be actively pursued and not just passively received.
The standard also indicates part of the feedback process should gather information on the production side of things as well. Things like scrap rate, percent of / trends in failed in-process or final acceptance tests, trends in rework, etc. should all be considered here.