IEC 62304 Class A Project

#1
Hi,

i have a question (big one i guess)

im in a small company which develops and manufactures special hardware(devices) for our customers. One of our customers wants us to develop a medicine product.

We are only 2 developer in the company (one guy is the hardware guy and i am the firmware/software guy). We have no "real" development process. Most of the communication with the customer is via Email and or sometimes meetings and we just "do" it. There is mostly no documentation, no planning no reviewing or anything. We obviously test our hardware and the firmware but there is no documentation about it either. (all of our projects are this way and this is what it was for the last 20 years - im in the company for the last 8 years and implemented at least GIT)

Now. The project is quite simple and "small" - we already have the last prototype of the hardware and the firmware for the device was like a 2 day coding job which ive done. Huray. The thing now is that my boss sold our customer IEC62304 documentation so our customer can get through the audit.

So.. now i have to make this documentation and ive gone through the IEC but im just overwhelmed. I did try to come up with something the last 1-2 weeks but im struggling with all of this. Im not more than a code monkey and dont have any clue about project management and management systems. My boss sold me this IEC (before we started the project) as like "just describe your code" - lol but it seems like its not that easy. or is it?

is there any way to get this done by myself in 2 weeks? because thats the time i have to finish it. (audit is in 3 weeks) maybe any templates i can use? i found this online maybe someone knows if thats ok to use Templates Repository for Software Development Process - Software in Medical Devices, by MD101 Consulting

thank you.

edit: project is class A. all risks are already adressed by the hardware. software can not harm anyone.
 
Last edited by a moderator:
Elsmar Forum Sponsor

yodon

Staff member
Super Moderator
#2
Indeed, that's a big question. And you're right, 62304 is not to "just describe your code" as you say. It's a lifecycle document covering Planning through Maintenance. Further, there is an expectation that you have your lifecycle process documented. This is even a bit more complicated since you won't be the company receiving feedback.

Do you have a copy of the standard? Some templates might help, but they won't be the answer.

If you (or your customer) have an option to get some outside help, that might be the only way to complete in 2 weeks. Even that might be a stretch. Both you and your customer need to get things in place.
 

Tidge

Quite Involved in Discussions
#3
Before writing anything else: Selling "IEC62304 documentation" (as described) doesn't exactly inspire confidence that your small company groks 62304. You have my sympathy, and I can offer some advice.

2 weeks you say? And that your part of the product was already developed? And you are essentially a supplier for the manufacturer of record?

What follows isn't intended to be a robust list to meet compliance with the standard but to hopefully meet the needs of the customer who contracted with you. He writes, not knowing what the contract says.

Necessary development deliverables for class A (consult the standard for full details, I hope your boss bought a copy of the standard for you!):

Software Development Plan: Since the work is already done, don't even try to pretend that you had one. The purchaser of your component should take responsibility for the SDP. It appears that their plan was "buy something that works". Similarly the manufacturer of record should assume all risk-management aspects of their device and the role your part plays in it.

Software Requirements: You should have been told "what the part needed to do". Document these as the requirements. Start a trace matrix keyed off the requirements.

Software Unit Implementation: Describe the "units" of the software and allocate them to the Requirements as appropriate. An easy way to determine what a unit is: A unit is the lowest level part of the code to which you could assign blame and/or fix.

Software System Testing: All software requirements require tests which demonstrate that they are satisfied. 62304 explicitly requires documenting 'input stimuli" and "expected outcomes" as well as established pass/fail criteria. A bulk of your 2 weeks are likely to involve thorough documentation of the testing. It is on the manufacturer of record to determine if your test strategies were adequate. The test record contents are spelled out in section 5.7.5.

Anomaly resolution: Anomalies need to be tracked. Ideally you have some sort of 'bug-tracking' system. 62304 also mandates that you retest after software changes. You will need to share the residual (left-over) anomalies with the manufacturer.

Finally, you will deliver the 'archive' of the software (sources, executables, etc.) with version numbers etc.
 

Ronen E

Problem Solver
Staff member
Moderator
#4
Hi,

i have a question (big one i guess)

im in a small company which develops and manufactures special hardware(devices) for our customers. One of our customers wants us to develop a medicine product.

We are only 2 developer in the company (one guy is the hardware guy and i am the firmware/software guy). We have no "real" development process. Most of the communication with the customer is via Email and or sometimes meetings and we just "do" it. There is mostly no documentation, no planning no reviewing or anything. We obviously test our hardware and the firmware but there is no documentation about it either. (all of our projects are this way and this is what it was for the last 20 years - im in the company for the last 8 years and implemented at least GIT)

Now. The project is quite simple and "small" - we already have the last prototype of the hardware and the firmware for the device was like a 2 day coding job which ive done. Huray. The thing now is that my boss sold our customer IEC62304 documentation so our customer can get through the audit.

So.. now i have to make this documentation and ive gone through the IEC but im just overwhelmed. I did try to come up with something the last 1-2 weeks but im struggling with all of this. Im not more than a code monkey and dont have any clue about project management and management systems. My boss sold me this IEC (before we started the project) as like "just describe your code" - lol but it seems like its not that easy. or is it?

is there any way to get this done by myself in 2 weeks? because thats the time i have to finish it. (audit is in 3 weeks) maybe any templates i can use? i found this online maybe someone knows if thats ok to use Templates Repository for Software Development Process - Software in Medical Devices, by MD101 Consulting

thank you.

edit: project is class A. all risks are already adressed by the hardware. software can not harm anyone.
Hi,

I'm not a SW expert, but it seems you already received valuable responses from 2 members. Unfortunately I can't add much on that.

One thing I do feel an urge to tell you (FWIW) is that your post portrays you as an intelligent and honest person. That combination seems to be quite rare these days. Just saying.

I hope you make it; you have definitely been put in a difficult situation.

All the best,
Ronen.
 
#5
thank you very much for your responses. glad to have found this forum!

first - yes i bought a copy of the standard. that also was the point were i realized that this is not just about "describing the code" (this for me is already a running gag because that were exactly the words of my boss) but im glad that im not crazy because nobody here is believing me that this is a big task. watched countless of yt vids about the topic and also subscribed to https:// codebeamer.com/ (if someone is familiar with) to see how automated tools are handling the IEC62304 so i can better understand what i have to do.

the project has two parts (its some kind of infrared sauna with radiators for heat control, audio, lights etc)
1) Hardware (based on IEC60601, if im not mistaken)
2) Firmware which resides in the hardwares microcontroller

our customer than takes our hardware and assembles everything together with their radiators, wooden cabin and what not. so we are just selling the hardware with a firmware on it.

@yodon: fun fact is that our hardware guy has help from an outside source which helps with the 60601 (and also helps our customer to approve for some ISO i forgot the name of) but this guy told me that he has no clue about the 62304. big issue here in my comp is that (not hating on older people ;-)) that im the "youngster" and most of the time its just like "yeah keep talking kid" - so they arent taking me always seriously aka they know better. but thats another topic #offtopic

@Tidge: thank you for your write up. the devil is in the details i guess. i think i will take the templates as a guidance in combination with the standard itself. and yes i know that i have to fake the whole development process, because there was more or less none. but nonetheless you said the SDP should be the responsibility of our customer? so the MANUFACTURER (from the standard) is >who< in this project? my company or our customer?

thanks @Ronen E for your kind words, really appreciate it.

is it ok to ask all of my futures questions here in this thread about our project or should i start a new one?

and again thank you all for your help!
 

Ronen E

Problem Solver
Staff member
Moderator
#6
i have to fake the whole development process, because there was more or less none.
Not sure; look at the SOUP provisions.
the MANUFACTURER (from the standard) is >who< in this project? my company or our customer?
Possibly is can be done both ways. It's just important to clarify which path you're going to follow right from the start, for consistency. Obviously the case where you are the Manufacturer will require more of you.
is it ok to ask all of my futures questions here in this thread about our project or should i start a new one?
I currently think it's better to continue in this thread rather than start others.
 

yodon

Staff member
Super Moderator
#7
the project has two parts (its some kind of infrared sauna with radiators for heat control, audio, lights etc)
If your firmware is controlling timers or LED banks (on/off) or heat control, you may not be as Class A as you think!

When your customer submits the product for testing under 60601-1, they'll likely need to submit a 62304 checklist - showing both how they (or you) have all the clauses covered procedurally and how (per applicable safety class) they have been fulfilled. As noted before, this will not be something for which they can completely rely on you.
 
#8
hi,

@yodon the firmware is not able to do any harm to the patient. the hardware has an watchdog so even if the firmware would not turn off automatically after 60min the watchdog should do. not handling LEDs just a general light (on/off) because colored LEDs are not medical at least thats what our customer told us. i think A should be fine here. the infrared sauna is basically a light switch. the radiators itself cannot harm the user even if they sit for 60min or longer @100% in front of them.

how do you mean they cant completely rely on me? ive talked to the 60601 guy and he said i have to do everything, because our customers does not have any "experts" which cant even tell us the exact specifications the firmware must have, so i should write it and just place their company logo on the sheet.. basically they completely rely on me. they know they want a "firmware which does the job" and thats it.

maybe you could elaborate which parts i cant do and only our customers does? thank you!!! sry for being this lost :-|
 
#9
One thing i would like to know is - how i should show "Traceability". or what it really means. i have for example Requirements which have IDs for example S-SMED-0001, S-SMED-0002 and so on. Now i have the "Verification Methods" which do have the IDs as reference. is this enough? same thing i guess goes for the reviews documents in the end? traceability just means that everything has a unique identifier so we know what we are talking about, right?
 

yodon

Staff member
Super Moderator
#10
how do you mean they cant completely rely on me?
If someone reports a problem with the system, are they going to contact you or your customer? If the issue turns out to be a software problem, are you going to notify the end users (I'm discounting regulatory bodies since it sounds like software could not be involved in an adverse event) or will your customer? @Tidge laid out a good set of deliverables that you can product but after the software goes to the field, there are still things to do.

One thing i would like to know is - how i should show "Traceability"
You need to show that all software requirements have been verified. If you have 1:1 relationship between requirement and test then you're probably ok.

The standard notes that software requirements trace back to system requirements (or other source) (see 5.2.6(f)). Not sure what you'll do if you don't have system requirements.

For small projects, I've seen a simple matrix (spreadsheet) showing the relationship between system requirements --> software requirements --> verification test. (So it's more than identifying, it's creating those parent / child relationships).

While compliance to the standard will be needed for 60601-1 support, it may not be all that's needed for clearance in the US (if that's their intended market). You (and your customer) should be aware of the FDA guidance for submissions of/containing software. Despite 62304 being a recognized consensus standard, FDA reviewers often fall back on this guidance when reviewing. I would advise you to document the Level of Concern (use the tables in the guidance). This can be incorporated in your Software Development Plan (or elsewhere). Also, FDA has recently been focusing on a few things. First is test metrics. I've had several customers say that they're being asked for code coverage assessments. In a similar vein, they've asked for code metrics as well (complexity). I'm sure it's a matter of what hot buttons the reviewer has. The other is cybersecurity. There's yet another FDA guidance (draft) on providing a cybersecurity assessment with the submission. If the device isn't connected to a network or has external interfaces, it's a pretty simple assessment.

Those are not needed to support the 60601-1 efforts so focus on the 62304 stuff first but I wanted you to be aware that it may not be all your customer needs.
 
Thread starter Similar threads Forum Replies Date
B Class IIB Device - IEC 62304 Software Classification IEC 62304 - Medical Device Software Life Cycle Processes 13
K Risk Reduction by Risk Control: IEC:62304-Class C ISO 14971 - Medical Device Risk Management 15
B IEC 62304:2006/AMD1:2015 Changes for Class A Software IEC 62304 - Medical Device Software Life Cycle Processes 3
W IEC 62304 vs. IMDRF SaMD Guideline Risk Class IEC 62304 - Medical Device Software Life Cycle Processes 5
O Electronic Fever Thermometer - Why not IEC 62304 Class C? IEC 62304 - Medical Device Software Life Cycle Processes 7
T IEC 62304 & FDA: Software Development Methodologies for Class II- DICOM device IEC 62304 - Medical Device Software Life Cycle Processes 8
K IEC 62304 - Functional and performance requirements for SOUP items IEC 62304 - Medical Device Software Life Cycle Processes 2
K IEC 62304 compliance - Code reviews as part of verification strategy IEC 62304 - Medical Device Software Life Cycle Processes 5
M Risk Analysis Flow - Confusion between ISO 14971 and IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
D IEC 62304 Risk Classification - With and without hardware control IEC 62304 - Medical Device Software Life Cycle Processes 2
B Clause 5.1.12 of Technical Standard IEC 62304/A1 IEC 62304 - Medical Device Software Life Cycle Processes 5
P IEC 62304 - evaluation of integration and system testing IEC 62304 - Medical Device Software Life Cycle Processes 4
P Risk acceptability alignment between ISO 14971 and IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 6
D Required Checklist Showing Compliance to IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 11
P Proposed revision of IEC 62304 - 2019 IEC 62304 - Medical Device Software Life Cycle Processes 6
S Relationship between IEC 62304 problem resolution and ISO 13485 IEC 62304 - Medical Device Software Life Cycle Processes 8
P IEC 62304:2006 A1:2015 - Software from the early 1990s IEC 62304 - Medical Device Software Life Cycle Processes 4
B IEC 62304:2015 vs IEC 62304:2006 + AMD1 IEC 62304 - Medical Device Software Life Cycle Processes 4
F IEC 62304 - Segregation and communication between software items IEC 62304 - Medical Device Software Life Cycle Processes 1
B IEC 62304 - Update Checklist IEC 62304 - Medical Device Software Life Cycle Processes 2
L Connection between IEC 62304 and Chapter 14 of IEC 60601-1 IEC 60601 - Medical Electrical Equipment Safety Standards Series 2
M IEC 62304 - Develop an Architecture for the Interfaces of Software Items IEC 62304 - Medical Device Software Life Cycle Processes 8
S Does IEC 62304 require documenting unresolved anomalies for all safety classes? IEC 62304 - Medical Device Software Life Cycle Processes 4
A SOP for software validation of software in medical device IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 5
T I need to make test reports according IEC 62304 & IEC 62366 IEC 62366 - Medical Device Usability Engineering 2
D Changing software classification via software - IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 3
D Software as risk control - Confused on one aspect of IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 20
K Trying to figure out what satisfies a few aspects of IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 2
Y IEC 62304 Section 4.3(a) - 100% probability of failure IEC 62304 - Medical Device Software Life Cycle Processes 3
Y Application of IEC/EN 62304 at an advanced stage of software development IEC 62304 - Medical Device Software Life Cycle Processes 4
T Is there any requirement to be compliant with IEC 62304 while implementing ISO 13485 ISO 13485:2016 - Medical Device Quality Management Systems 5
L Documentation Planning - IEC 62304 Clause 5.1.8 IEC 62304 - Medical Device Software Life Cycle Processes 2
C Software for Medical Devices - Requirements Content for compliance with IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 1
W CPU BIST IEC 62304 - Embedded code has CPU instruction tests IEC 62304 - Medical Device Software Life Cycle Processes 2
K IEC 62304 Amd 1 2015 - Figure 3 – Assigning Software Safety Classification IEC 62304 - Medical Device Software Life Cycle Processes 11
C Per IEC 62304, are DHF documents Configuration Items? IEC 62304 - Medical Device Software Life Cycle Processes 5
P IEC 62304 AMD1:2015: What's new vs.the 2006 Edition? IEC 62304 - Medical Device Software Life Cycle Processes 4
F FDA PMK 510(k) - IEC 62304 Software Components Segregation Other US Medical Device Regulations 3
M IEC 62304 Applicability - GUI Control Software IEC 62304 - Medical Device Software Life Cycle Processes 3
B Our NB says that IEC 62304 is an ISO 14971 Requirement ISO 14971 - Medical Device Risk Management 1
B Clarification on interpretation of some EN ISO 14971:2012 & IEC 62304:2006 req's ISO 14971 - Medical Device Risk Management 46
H ISO 14971 vs. IEC 62304 vs. 98/79/EC vs. ISO 13485 (Software Medical Device) ISO 14971 - Medical Device Risk Management 1
D A desperate call for help - IEC 62304 software IEC 62304 - Medical Device Software Life Cycle Processes 5
M IEC 62304, ISO 14971 and FDA Medical Device SW Guidance 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 5
K IEC 62304 - Compliance steps IEC 62304 - Medical Device Software Life Cycle Processes 2
K ISO 14971 and IEC 62304 - Medical Device Software House ISO 14971 - Medical Device Risk Management 9
S Software Test Report including IEC 62304 classification IEC 62304 - Medical Device Software Life Cycle Processes 4
A Mapping of IEC 62304 artefacts (SRS, SAD, etc) to the 820.30 phases IEC 62304 - Medical Device Software Life Cycle Processes 5
C New IEC/TR 80002-3 Guidance for IEC 62304 - June 2014 IEC 62304 - Medical Device Software Life Cycle Processes 2
R IEC 62304 was brought up during an FDA Inspection/Audit IEC 62304 - Medical Device Software Life Cycle Processes 6
Similar threads


















































Top Bottom