In that part depending on how many revisions there are or what type of documentation you can either have this directly in Section 16 - Software or a separate document attached as an Exhibit. What I do is just make a simple table with columns for build number, date of build/release, responsible person and then a brief description (release notes) of the build/version. Many people ask to what level of detail of versions or builds should be listed, i.e. do you list version 1.1.2.1, 1.1.2.2, 1.1.2.3, 1.1.3, etc. I usually just include "significant" or major builds in the revision history.
------------------------------
Richard Vincins RAC
Vice President Regulatory Affairs
------------------------------
Original Message:
Sent: 24-Jul-2018 12:32
From: Loganathan Kumarasamy
Subject: Software revision history
Hi Rashmi,
In general, there will be cases where we would have made changes to software after it was submitted for review to meet some technological advancements or other reasons. There will also be internal changes made to the software after it was validated and not released for the market.In such cases plus general scenario, it is important to list the major changes happened to the medical software along with when it was officially released, why the change is being made and if there is any impact to the safety and effectiveness of the device. There could also be additional software components utilized, which also needs to be versioned and included in the revision changes.
------------------------------
Loganathan Kumarasamy
Senior Consultant
Waukegan IL
United States
Original Message:
Sent: 24-Jul-2018 02:59
From: Rashmi Pillay
Subject: Software revision history
Hi,
Can somebody tell me what is the 510 k requirement for this document? I know what the guidance says but what level of revision history is required, is all the development history before the release of the first version also required? Is there an example anybody could share.
Regards
Rashmi