Hi,
Could anybody help me on the following query regarding managing patch releases of a software system which I am currently validating. I understand that version number of the software identifies the unique construct of the system and all system releases thereafter are tracked for example using the following numeric format 10.2.12.1{version.release.build.patch}. A build is created for a particular version and a patch is a special build which replaces specific files within a version.release.build. When documenting the release number of the software the combination of version.release is the number published and during IQ the build ID was identified and documented thus establishing that the build of the version met the correct requirement specifications.
My query is as follows; Once the software system is in operational use and service releases become available with patches is there a specific way to determine which patches need to be put in place in the operational system?
I presume that a risk based approach would be used to determine if security and software bug patch fixes need implementation and other patches would be considered based on business needs- is this common practice?
Furthermore, if the patch is implemented, is further validation required or does vendor documentation suffice if it demonstrates that the patch fix is standalone?
The reason I ask this is because the build no. is related to the version no. and the patches are special builds encorporated as part of seperate service releases, therefore, if it has previously been demonstrated that the build for the version meets all specifications can successive releases of software with same version and build be implemented without validation?
Appreciate if anybody could help.
[quote=confused.com]Hi,
Could anybody help me on the following query regarding managing patch releases of a software system which I am currently validating. I understand that version number of the software identifies the unique construct of the system and all system releases thereafter are tracked for example using the following numeric format 10.2.12.1{version.release.build.patch}. A build is created for a particular version and a patch is a special build which replaces specific files within a version.release.build. When documenting the release number of the software the combination of version.release is the number published and during IQ the build ID was identified and documented thus establishing that the build of the version met the correct requirement specifications.[/quote]
So is the system already validated or are you in the middle of validation now, and a new patch is being relased in the middle of your validation exercise?
Not sure what you mean here, are not all patches critical to your system, its not as if you can pick and choose which ones you like.
[quote=confused.com]
I presume that a risk based approach would be used to determine if security and software bug patch fixes need implementation and other patches would be considered based on business needs- is this common practice?[/quote]
Well I would assume all security patches are essential to the correct working of the system - in terms of bug fixes I guess you could put off these if they dont interfere with your business flow, but what happens when the next major release comes about these will have to be implemented anyway.
[quote=confused.com]
Furthermore, if the patch is implemented, is further validation required or does vendor documentation suffice if it demonstrates that the patch fix is standalone?[/quote]
As with the intoroduction of GAMP 5 I would try and leverage off the vendor documentation if possible. Why not raise a change control SOP for the system and reference the vendor documentation, then you have full traceability
Hope this helps
Software version numbering is haphazard at best. A fair bit of it is marketing related. You certainly cannot draw anything meaningful from all but a few vendor numbering schemes.
You also need to take into account hotfixes as well as patches. And often a hotfix could just be issued for one user that is completely unsuitable for another.
In my opinion, a good validation strategy documents and tracks hotfixes and patches but without excessive actions required any time something changes.
–
Not all patches are mandatory either - some are highly not recommended. “If it ain’t broke, don’t fix it” - I am big on computer security, but in a restricted access pharmaceutical system I often don’t see the need to willy nilly apply the latest security patches. I’ve seen lots of systems running with NT, 2000, UNIX etc. that have never been patched.
Hi,
Thank you for the feedback.
In response; the system is currently still in Validation stage in PQ phase.From analysing the patch release document recieved from the vendor there have been a number of patch releases since the installation of our software. I am in agreement of the idea of “leave well enough alone” if it suits our current usage and take on board both suggestions regarding the necessity to implement security patches.
Thanks:)
I trust that you are not turning out to be a beta site for testing someone’s software - a storm of patches and hotfixes normally disturbs me a bit if it pertains to the end application (exception being the monthly patch cycle from the operating system manufacturer, which is normal nowadays).