Configuration Management - Identifying Documentation

[RedDevil_AK]

Hi Cove,

I am a RA Specialist at a startup, and am writing a Configuration Management Plan for an SaMD product. The developers use Confluence a lot for internal documentation like release notes and information about noteworthy JIRA epics and tickets. I'm trying to figure out how to include this in the CMP, there's no SOP that controls this aspect - should I just mention that release notes are documented with the version number in Confluence with any changes controlled? We do have a doc control SOP that covers the identification of quality documents, but I'm not sure if everything that is in Confluence can be covered under a doc like the DHF or something similar.

Appreciate any inputs. Thanks!

 

[yodon]

release notes and information about noteworthy JIRA epics and tickets

Is it important to maintain the configuration of these items? They aren't explicitly called out as deliverables under 62304. (I am assuming that you have other, stand-alone release documentation to cover all the aspects in 5.8 of the standard.)

 

[mihzago]

It would be a good idea to at least describe in your CMP how all the different documents, artifacts and data are managed so it's consistent and everyone on the project understands where everything is and how controlled.

Anything that is required by the regulation or standard has to be controlled, but it's up you to how you do that.
Since you mentioned DHF, I assume you have to comply with the QSR, so consider records that are required for the Device History Record (I typically use release notes) or Design Transfer (master executable, archive, build and deployment procedure, etc.).

 

[RedDevil_AK]

They aren't explicitly called out as deliverables under 62304.

I'm not very concerned about the JIRA epics/tickets, but the release notes would be important for 5.8.4, part of 5.8.5, and 8.3, and also as @mihzago mentioned, the DHR.