I have found that in practice, for developing medical device software, there are two distinct phases of anomaly tracking:
1) During development (anomalies are part of the project)
2) Upon release and while on-market (anomalies are part of the product)
It is mandatory, per regulators, to have anomaly tracking during (2). Anomaly tracking also plays into the Software Maintenance and Software Problem Resolution processes of 62304.
The anomaly tracking that occurs during development is more of a sliding scale. Many developers implement formal anomaly tracking during system testing because attempts to resolve anomalies can obviously, directly, have an impact on previously executed testing... and a rigorous anomaly-handling process can direct work and provide the safeguards necessary to avoid repeating work. Implementing a slightly(*1) more rigorous anomaly-handling process earlier in development can reap the same benefits, it is up to the software developer manager (and her development plan) to decide how much undirected and wasted effort she will tolerate prior to system testing.
Typically, unresolved anomalies from (1) become the baseline for the anomalies list in (2)... which is a contributing factor why many managers don't like to start tracking anomalies too early... but this is is sort of like "see no evil, speak no evil, hear no evil".
(*1) During development, prior to system testing, there is IMO no need to bring "medical device risk management" into anomaly handling... anomalies (at unit level, for example) could just be (1) document issue (2) identify area of software to be modified (3) description of change made (4) verification that issue is resolved. In order to satisfy the release/on-market anomalies for medical device software, there will have to be a formally documented risk assessment.