What if you knew where to look for critical defects….?
There you are in the middle of a large-scale hospital systems project, where new medical devices need to integrate with several clinical & billing applications – and there seems to be no end to requirements changes.
Eventually there will be a halt to the scope creep, but in the meantime – there have been endless changes and the systems engineers have barely kept up with all the documentation updates to reflect the changes.
And of course, every technical change generates vast amounts of unavoidable QMS work – which cause additional project delays.
Meanwhile; the R&D and SQE Teams are going as fast as they can, making sure all requirements (and related spec’s) are covered in the continually updated test plan/strategy documents – and are reflected in updated/added test cases – while ensuring the traceability matrix has been properly updated.
How do you go about identifying all the high-risk areas in the code for the device and interconnected systems – without delaying the project indefinitely – until you can achieve 100% confidence that you’ve discovered all the critical defects residing in the code?
It’s always easy to say: ‘we have complete requirements test coverage’, yet everyone has a wavering level of confidence in the team’s ability to find & remove all the critical defects, while racing to meet deadlines.
Add another layer of concern; you also need to make sure the system will handle all the data traffic within the system (round trip from clinical datasets out to the devices, and all the device activity logs transmitted back to the hospital systems, including connected billing applications) without any delays – while multiple users access the system, simultaneously, throughout the hospital.
You can’t allow data loss or corruption, or system performance degradation while system search or reporting processes are executed.
Here is the million-dollar question:
What if there was a process which allowed you to reveal all the blind spots throughout the system, (including areas with critical defects generated by unusual circumstances), where core functionality and performance killing faults are hiding – so you could find and mitigate them prior to project release?
Imagine a process, based upon failure mode and effects analysis – created in the 1950’s to solve hardware issues in military systems – that’s been updated for 21st Century embedded, enterprise and cloud engineered medical systems and devices, and it can genuinely prevent product recalls from happening.
We call it Recall Prevention, (the underlying Risk Reduction Process is what makes it all work), and we’d be happy to share it with you.
Back to the original question: what if you knew where to look….what would you do differently?
