Do change requests play a role during initial development, before a release took place?

When developing medical device software under IEC 62304, do change requests play a role during initial development, before a release took place?

I've always had a software release process, even for pre-market software builds. They usually have a scalable set of activities associated with each release, depending on exactly where in the life-cycle the software is.

For example: If the software has undergone some testing, it makes sense that there would be an assessment about which testing needs to be repeated. If the development team simply wants to get a candidate release out to other internal stakeholders, perhaps for that other group to begin developing test protocols, then all that may be needed is an establishment of provenance about what went into that build.

That's always a challenging topic. Developers don't want to be "bothered" until after release, but there are valid reasons for doing so earlier (i.e., in development). The point @Tidge makes about (after undergoing) "some testing" can also be difficult to pin down. Does unit or integration testing count here? 62304 states that the "problem resolution process" (classes B & C) is used if 'anomalies' are found in integration testing so that seems like a reasonable point. We often find things in unit verification that we want to fix but defer for some reason and so we drop in issues at that point.

Specific to unit/integration testing: My experience has been that these tests are not done on "fully compiled" software, which is what I always associate "software release" to encompass. Obviously the provenance for the units has to be established and maintained (through configuration management), but that is something I consider to be different that "software release".

This can get quite tricky if verification of software system requirement gets allocated to testing done at the unit level.

Mileage varies of course. Writing only for myself: I expect the software development team to have implemented a software configuration management process, long before they even consider software releases.

We use two terms to define anomalies. Engineering anomalies which are detected as part of any type of testing (unit/integration/system) for a feature which is under development. These anomalies are fixed as part of the debugging process and no formal change requests are required. After functionality is completed - any anomalies found after closure of the feature is reckoned as a anomaly which is to be tracked with a change request. This helps when doing incremental development when you have to do quite some testing to improve the quality.