Software validation | Joe Hagan-Brown

The main media story locally in the UK in January 2024 has to be the Post Office scandal relating to the faulty Horizon IT system and the unjustified prosecution of Post Office Ltd Sub-Postmasters.

Paul Patterson, director of Europe's Fujitsu Services Limited admitted today during the ongoing public enquiry that the IT system, which was developed and supported by Fujitsu, had known bugs and errors. Clearly there was either a lack of appreciation or a lack of care on the part of Post office limited and Fujitsu as to the risks these bugs and errors could pose to end users.

In the case of the Horizon IT system, these bugs and errors have led to the loss of businesses, wrongful prosecutions and unfortunately have almost certainly contributed to the death of some victims due to psychological stress.

Bugs and issues should be found during the final ‘tests’ which are done by the development team after the product has been built or coded. Before software products are released/’go-live’, they should be checked to make sure bugs and issues are identified, the code works, and the user experience is as it is supposed to be. This is software validation.

In the medical device industry, where patient lives and wellbeing routinely depend on safe and effective products built to a high quality, ISO 13485:2016, which represents the consensus state of the art in medical device quality management, recognises the importance of software validation. Clause 4.1.6 stresses the importance that Software used in the QMS needs to be validated. clause 7.5.6 of ISO 13485:2016 furthermore explicitly mandates there to be procedures for the validation of software used within the production and service provision process in particular.

Frankly, it is actually quite normal for software to be released with known bugs and issues. However, as a part of the design and development process - in particular during software verification and validation, such bugs should at least be identified (through test activities), investigated, risk assessed, and reviewed against the specifications for the product, by the development team. Once the extent, severity and potential impact of the bugs and issues are understood, the development team can then make a decision as to whether to fix it now, or later.

This method of agile, incremental software development, when done in a controlled manner usually means any serious bugs get fixed before the end user experiences any problems. Non-serious bugs go-live but are fixed in a future software update as a lower priority issue. Ultimately the end user is happy with the final product which gets released and it is delivered in a timely and resource-mindful way.

Have you checked to make sure your organisations QMS and Production software does what it is supposed to do? Have you validated your QMS software?