SOUP (Software of Unknown Provenance) Anomaly Documentation

KrishQA

Starting to get Involved
#1
Hello all,

We are developing a class C medical device and have evaluated a list of SOUP anomalies from the manufacturer. Just want to know what is a typical way of documenting the list of anomalies that were evaluated.
  • Part of a risk analysis session?
  • Include the anomaly list in the architecture document?
  • Link the online SOUP list from manufacturer directly (this would be prone to change of links/reference)
Looking to see how you would document it best
 
Elsmar Forum Sponsor

shimonv

Trusted Information Resource
#2
Linking to an online SOUP resource is not a good idea and you have no control over.
What I've seen done a couple of times is SOUP report that includes, among others, a description of known defects.

Shimon
 

Tidge

Quite Involved in Discussions
#3
At a minimum, you should capture the known state of the SOUP at the time you implement it, including any published anomolies. As @shimonv hints, the online resource could evaporate leaving you with no records. It used to be the case that suppliers of SOUP-y things like chipset-specific compilers and libraries would remove all links and documentation for almost any reason: The chipset is no longer produced, the mfg has a new suite of tools, etc.

There are many possibilities as to "where" you want to keep a record of the review of SOUP anomalies. I hesitate to be prescriptive, but a simple answer is "however you handle the review of anomalies before launch... why not review the known SOUP anomalies the same way, but as a single unit?" (1) Different companies will take a different approach to maintaining the anomaly list (post-launch); most companies are uniform in their approach that closed/resolved anomalies are not kept on a post-launch anomaly list, but are instead archived as part of the development process. (2)

I cannot guarantee the behavior/expectations of any external reviewer when it comes to software; I've seen some that keep strictly to deliverables, I've seen others obsessed with seeing raw source code. My personal experience is that there is more variability among external reviewers of software (both in the development of software in devices, as well as software control of processes) than in any other compliance area.

(1) Anomaly tracking should include risk analysis for both open/closed anomalies, but not every software anomaly's risk analysis necessarily requires a line of analysis in a risk file. For example: during initial development, a piece of code that simply doesn't work and requires rework to meet a requirement wouldn't necessarily have or need a dedicated risk analysis line, as the risk is simply that requirements aren't met. If the code is used without rework and still doesn't meet requirements, that's a bigger issue as it is an unresolved anomaly which you'll be carrying forward.

(2) If there is a SOUP anomaly than contributes to risk (pre- or post-controls) I would expect it to be analyzed in a risk document such as a Software HA, especially as you have no control over the SOUP and don't have the option of 'fixing' it. If there is a SOUP anomaly cannot be resolved, then I would expect such a specific anomaly to carried forward on the post-launch anomaly list.
 
Thread starter Similar threads Forum Replies Date
J Custom Tools as SOUP? (Software of Unknown Provenance) IEC 62304 - Medical Device Software Life Cycle Processes 9
A OTS and SOUP Software Documentation Requirements Other US Medical Device Regulations 9
K IEC 62304 - Functional and performance requirements for SOUP items IEC 62304 - Medical Device Software Life Cycle Processes 2
F Firmware as SOUP - Sensor with third party produced firmware IEC 62304 - Medical Device Software Life Cycle Processes 2
K SDK: SOUP or not? IEC 62304 - Medical Device Software Life Cycle Processes 8
P SOUP anomaly evaluation for MMA IEC 62304 - Medical Device Software Life Cycle Processes 2
J Converting SOUP to "SOKP" ... IEC 62304 - Medical Device Software Life Cycle Processes 1
U The Importance of Correct Sample Size Calculation - Greek Alphabet Soup Book, Video, Blog and Web Site Reviews and Recommendations 7
Y UL 1998 Standard: software classes Software Quality Assurance 0
P Need a programmer for QVI's VMS software for optical inspection machine Inspection, Prints (Drawings), Testing, Sampling and Related Topics 0
S IEC 62304 software costs and time Medical Device and FDA Regulations and Standards News 2
S IEC 62304 - Software verification cost IEC 62304 - Medical Device Software Life Cycle Processes 3
Sravan Manchikanti Software Risk Management & probability of occurrence as per IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
I Form templates for software (iso9001) Document Control Systems, Procedures, Forms and Templates 0
H Software Interface Translation IVD Regulation EU Medical Device Regulations 0
C 8.5.1.1 Control of Equipment, Tools, and Software Programs - Questions about the extent of control of NC programs AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 5
M IEC 62304 Software changes - Minor labeling changes on the GUI IEC 62304 - Medical Device Software Life Cycle Processes 3
silentmonkey Rationalising the level of effort and depth of software validation based on risk ISO 13485:2016 - Medical Device Quality Management Systems 10
T Do I need a qualified compiler for class B software? IEC 62304 - Medical Device Software Life Cycle Processes 3
S Manufacturing Execution Systems Software Costs Manufacturing and Related Processes 0
E 13485:2016, Sections 4.1.6, 7.5.6 and 7.6 - Validation of Software - Need some Advice please ISO 13485:2016 - Medical Device Quality Management Systems 2
R Medical Device Software Certification IEC 62304 - Medical Device Software Life Cycle Processes 1
S HIPAA-compliant monitoring software (advice needed) Hospitals, Clinics & other Health Care Providers 0
A Software bug fixes after shipping a product EU Medical Device Regulations 3
J Medical software Patient outcome Medical Information Technology, Medical Software and Health Informatics 2
Y We are Looking for EASA LOA TYPE 1 experienced software developer Job Openings, Consulting and Employment Opportunities 0
F Grand Avenue Software, Q-Pulse or Qualio - which for a full eQMS? Medical Information Technology, Medical Software and Health Informatics 1
Q Storing and developing SAMD (Software as a Medical Device) in the Cloud IEC 62304 - Medical Device Software Life Cycle Processes 2
I Old Time Scatter diagrams for defect type and location- software Quality Tools, Improvement and Analysis 3
SocalSurfer AS9100 new certificate, but need QMS software, help Quality Assurance and Compliance Software Tools and Solutions 2
C Is my software an accessory? Telecommunication between HCP and patients EU Medical Device Regulations 10
K Verify Software Architecture - supporting interfaces between items IEC 62304 - Medical Device Software Life Cycle Processes 1
A What are the pros and cons of using an audit software for internal auditing? General Auditing Discussions 4
A Risk Number for each software requirement IEC 62304 - Medical Device Software Life Cycle Processes 7
R Shall a new UDI-DI be required when stand-alone software device's version is updated? EU Medical Device Regulations 1
R MSA for ATE (Automatic Test Equipment Embedded Software) Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 9
S MDR GSPR Clause 17 - Software Requirements EU Medical Device Regulations 2
L Turkish Requirements - Does the Software need to be translated? CE Marking (Conformité Européene) / CB Scheme 2
MDD_QNA Medical Device Software - Is a Help Button required? IEC 62304 - Medical Device Software Life Cycle Processes 1
F Software as a Medical Device (SaMD) Technical File Requirements Manufacturing and Related Processes 1
D Software User Interface Languages for LVD and IVD CE Marking (Conformité Européene) / CB Scheme 2
A Software as Medical Device (SaMD) definition and its applicability Other Medical Device and Orthopedic Related Topics 4
K Software Validation for Measurement Tools used in Process Validation ISO 13485:2016 - Medical Device Quality Management Systems 2
B ISO 14971 Applied to Software ISO 14971 - Medical Device Risk Management 2
N ERP Software Implementation Manufacturing and Related Processes 3
C NCR (Nonconformance System) Software Nonconformance and Corrective Action 7
U Document Approval - Software company ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
B Risk Assessment Checklist for Non product Software IEC 62304 - Medical Device Software Life Cycle Processes 1
MrTetris Should potential bugs be considered in software risk analysis? ISO 14971 - Medical Device Risk Management 5
S SOP for ISO 13485:2016 Quality related Software validation ISO 13485:2016 - Medical Device Quality Management Systems 9

Similar threads

Top Bottom