Segregation of Software Items on a Medical Device

A

alexeyb

#1
My company is developing a system in which there are 4 software items:
  • Firmware which runs on an embedded device
  • Software which controls the device from a PC
  • Database controller
  • Production test software
The current approach we are employing is that each of these items have seperate SRSs, architectures, test plans, etc. I would like to know if this type of segregation makes sense, if others follow the same approach, or have other ways?
 
Elsmar Forum Sponsor

yodon

Staff member
Super Moderator
#3
Yes, that makes sense... as long as you have a "big picture" view somewhere. I've seen several ways to approach this.

1) What's pretty typical is to have a system spec that outlines all this. The system spec is not software-centric but provides the foundation for the overall architecture.

2) Have a high-level software spec that provides the overall structure.

In either case, the individual software specs need to trace back to their respective parent specification(s). So the more layers involved, the more complex the trace tree gets (which is why it's more typical to see the system spec trace directly down to the individual software specs).

To also help tie things together, where interfaces exist between the components, you should have an Interface Control Doc / Spec. And you'll want to verify (robustness of) both sides of the interface.
 

c.mitch

Quite Involved in Discussions
#4
Segregation is at first a risk mitigation action based on software architecture.
You split your software in elements with well-defined interfaces between them, to mitigate the risk of propagation of a software failure from one element to another.
The documentation is only here to show the segregation actually in place.
IMHO, the risk assessment report should contain the reason of this segregation: software hazards, and architectural mitigation actions.

So, yes, this is a solution to split documentation the way you split your software. But you have also to describe the rationale of this segregation.

BTW: Is the Production test software a medical device? If it is only used in factory and not in customer's facilities, there are good chances this is not a medical device but a production tool.
 

Peter Selvey

Staff member
Super Moderator
#5
"Segregation" simply means keep separate; in the context of IEC 62304 it can have several effective meanings, even the standard uses it for different meanings in different places. In one place it is used for classification, in another (5.3.5), it has the double channel meaning, generally for high risk devices like a surgical laser or infant incubator.

The original question has the highest level meaning, which is in effect "what is a software system?"

IEC 62304 applies to the medical device, which is the object that is actually placed on the market. For each medical device which contains software, there should be at least one software system and hence one SRS.

The original question had four types of software related to the medical device. So we really need to ask first: is each one a medical device? The firmware seems to be yes, PC software and database maybe, and the production software seems to be no.

The next question is: are they sold as a package or as individual medical devices? If for example the device with the firmware, the PC software and/or the database are sold or placed on the market separately, then definitely you need individual SRSs to comply with regulations.

If they are sold as a package (single medical device), then it is flexible. In practice, if there are two or more processors (e.g. firmware, PC software), it makes a lot of sense to separate into individual SRSs. It gets too complicated otherwise. Of course, there should still be a "system specification" for the final medical device (hardware/software/mechanical etc) that ties everything together, including the interconnection of the two software systems. But that is out of the scope of IEC 62304.

The key point it to always have in mind the "medical device", and the work top down from there. If you have an SRS for the firmware, it should somehow fit within that framework.

For the production software, there is no requirement to control as a "software system" under IEC 62304. You only need to meet Clause 5.8.5 (document how software is released), there is no need for an SRS, risk management, configuration management etc etc.
 
Thread starter Similar threads Forum Replies Date
F IEC 62304 - Segregation and communication between software items IEC 62304 - Medical Device Software Life Cycle Processes 1
F FDA PMK 510(k) - IEC 62304 Software Components Segregation Other US Medical Device Regulations 3
R Medical Device Software Segregation and Detailed Design IEC 62304 - Medical Device Software Life Cycle Processes 10
A How is Segregation of Duties defined in the IT World? IEC 27001 - Information Security Management Systems (ISMS) 4
J Segregation of duty checklist for the IT department Internal Auditing 2
T Waste Segregation and Recycling - Ideas for Launching & Jazzing up 'Green Day'. Sustainability, Green Initiatives and Ecology 1
H Audit Segregation by Product - ISO 9001 & AS 9100 in a small machine (job) shop AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 6
C Is there a Solid Waste Standard Segregation Color Coding Miscellaneous Environmental Standards and EMS Related Discussions 7
Q Seeking Best Practice of Parts Segregation Manufacturing and Related Processes 1
D Segregation of Product by Type and Production Week - Warehouse General Auditing Discussions 2
S Control of NCM: segregation strategies QS-9000 - American Automotive Manufacturers Standard 1
Q Software as a medical device vs software not sold as medical device: local regulations for sale? EU Medical Device Regulations 4
Y Software updates considered servicing (7.5.4) ISO 13485:2016 - Medical Device Quality Management Systems 4
S How to perform verification of the Statistical Analysis Software? Qualification and Validation (including 21 CFR Part 11) 2
I Document Control Software Document Control Systems, Procedures, Forms and Templates 2
E Software maintenance Process Software maintenance Process to IEC 6204? IEC 62304 - Medical Device Software Life Cycle Processes 3
L Micro-Vu InSpec Software Program Qualification and Validation (including 21 CFR Part 11) 6
A For software change - New Channel of interoperability CE Marking (Conformité Européene) / CB Scheme 4
T IVDR Medical device software CE Marking (Conformité Européene) / CB Scheme 8
N ISO 13485 7.3.9 Change control in medical device software ISO 13485:2016 - Medical Device Quality Management Systems 6
C SharePoint Contract Management Software General Information Resources 0
gramps What do you think about automated QA testing For software app industry? Misc. Quality Assurance and Business Systems Related Topics 5
V Software as medical device (SaMD) replicated for multiple clients through APIs IEC 62304 - Medical Device Software Life Cycle Processes 5
U API Spec Q1 - 5.6.1.2 C (3) - Design software Oil and Gas Industry Standards and Regulations 3
B Complaint Records - Accessing records on Easy Track Software Records and Data - Quality, Legal and Other Evidence 3
GreatNate Master Control QMS software Quality Tools, Improvement and Analysis 0
GreatNate Anyone using the Intellect QMS software? Quality Assurance and Compliance Software Tools and Solutions 1
S DHF/DMR/MDF for a software-only, cloud-based, single-instance device Medical Information Technology, Medical Software and Health Informatics 2
H Software Validation for FFS Packaging Machine Qualification and Validation (including 21 CFR Part 11) 1
E Any sample of a full software life cycle IEC 62304 report ( any class )? IEC 62304 - Medical Device Software Life Cycle Processes 1
Q ISO 13485 7.5.6 Validation - Off the shelf Software ISO 13485:2016 - Medical Device Quality Management Systems 3
M ERP / QMS related software standards for Validation IEC 62304 - Medical Device Software Life Cycle Processes 6
J Do Software Subcontractors need to be ISO13485 compliant in the EU? EU Medical Device Regulations 3
D Safety data sheets software REACH and RoHS Conversations 2
N What are the software audit and control steps Reliability Analysis - Predictions, Testing and Standards 2
N Validating Software before getting approved as Class 2 device US Food and Drug Administration (FDA) 5
M Clinical Decision Support Software Question 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
P Missing 1m visual alarm signal in case of software/display failure, mitigation? ISO 14971 - Medical Device Risk Management 3
B Software service provider as critical supplier ISO 13485:2016 - Medical Device Quality Management Systems 5
S Asterisk in DOE minitab software Using Minitab Software 23
M Surgical angle measurement guide device with an application software Medical Device and FDA Regulations and Standards News 1
M Advice needed for SEH Compliance Software and ISNETWord Compatabiliy Occupational Health & Safety Management Standards 2
bruceian Software Quality Metrics Software Quality Assurance 11
optomist1 How Secure Are Our Software Systems Software Quality Assurance 7
M 'Active' device? Software/laptop with attached camera 'looking' at passive metal probe EU Medical Device Regulations 3
D Software validation team Misc. Quality Assurance and Business Systems Related Topics 3
O Any info on release date of FDA “Computer Software Assurance for Manufacturing and Quality System Software” document? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 0
L Radiology software Class I exemption Medical Device and FDA Regulations and Standards News 3
O Software for comparing text of PDF files Contract Review Process 2
J Implementing an ISO 13485 QMS Software ISO 13485:2016 - Medical Device Quality Management Systems 6

Similar threads

Top Bottom