< 1 min reading time

As originally asked by Erica Reid.

---

Jeff McBride
Quality Representative at Medopad
I find that each technology/language already has a set of standards that can be used to meet most of the regulatory requirements. The additional ‘pieces’ are just a set of high level ‘ideals’, e.g. a naming/numbering convention for the product line, annotaion on a (code) line-by-line or function-by-function basis (depending on Risk etc.), use of CASE tools for monitoring bugs, etc.

John Hoppe
Owner, VacuMed
Is anyone willing to post a sample coding standard? That way some of the experienced people above could offer comments about what’a right and what’s wrong?

Jeff McBride
Quality Representative at Medopad
Software developers are by nature (this is a generalization, so obviously some are not) averse to adhering to rigid standards. Often this can result in code, however good, that is difficult to ‘untangle’ and understand by other than the original author.
That, in itself, can lead to there being functional ‘bugs’ that can go undetected at the development and testing phase. This is a big challenge when dealing with large software.
Detailed Specifications prior to coding are a help, as are coding standards, especially insisting on a high level of annotation and meaningful naming/numbering conventions.
Peer review of the developed software, including reference to both Specs and testing is also a big help, especially if this is documented in an appropriate manner.

William Buras
Senior Director, Life Sciences R+D at Tietronix Software
Erica

IEC 62304 is a good standard to start with. I would also refer you to ISO 13485 for important guidance on higher level design controls which will be important if you will be seeking either EU or FDA regulatory clearance in the product path you envision.

Unfortunately, good/preferred software development practices for medical device software development are not easy to develop from simply reading those standards. If you have experienced developers that have operated in an environment where good software engineering practices were learned, you have a great start. If instead you have smart people that have learned to hack out code and then debug until an acceptable code (or codes) are produced, you can’t really go backwards to create the quality engineering practices needed (and required by regulations).

You also will need a healthy understanding of risk management/risk mitigation commensurate with the level of controls attendant to your device (is it Class I, II or III).

Its very common for entrepreneurs, scientists and even smaller design shops to approach the software development part of a device as a “sub-assembly” that presents an opportunity to save time and money when prototyping. This is fine for general prototyping purposes, but unlikely to pass regulatory scrutiny, or due diligence assessment by potential acquirer. In this case I would recommend going with a very common language (like C, C#, JAVA, etc) The reason is that it will be easier for a professional medical software development organization to take over the code and bring it up to standards later. If you use less common development environments you would then force a total re-code.

Good luck!

William

Andrew Dallas
Principal, DallasMedTech providing strategic guidance to medical and life science companies.
Sorry, I can’t agree with Kim Kwan above regarding avoiding dynamic memory allocation. Each language has its benefits such as type safety, portability, reflection, etc. Dynamic memory allocation is a perfectly acceptable practice and modern tools allow us to rapidly diagnose misbehavior such as memory leaks, stack overruns, memory leaks and more.

Now regarding coding standards, yes, I couldn’t agree more with many of the posters above. Coding standards allow engineers to more easily adopt others code, allows code standard tools to provide early detection of potential errors and helps teams to build cohesive applications that follow good design principles.

Kim Kwan
Vice President of Research and Development at Cognito Therapeutics, Inc.
For C & C++, some rules in MISRA coding standard are quite applicable to medical device software such as “avoid dynamic memory allocation”. See https://www.linkedin.com/redir/general-malware-page?url=http%3A%2F%2Fen%2ewikipedia%2eorg%2Fwiki%2FMISRA%7Cleo%3A%2F%2Fplh%2Fhttp%253A*3*3en%252Ewikipedia%252Eorg*3wiki*3MISRA%2F2ZtN%3F_t%3Dtracking_disc%5D

Erica Reid
Communications and Admissions Coordinator
Thanks so much! That is really helpful.

Steven Crook
Consultant Clinical Scientist (NHS) and Quality and Regulatory Manager (Medical Device company)
Hi Erica,
This article may be helpful. [http://www.emdt.co.uk/article/developing-medical-device-software-iso-62304|leo://plh/http%3A*3*3www%2Eemdt%2Eco%2Euk*3article*3developing-medical-device-software-iso-62304/3xNp?_t=tracking_disc]
We had to buy 62304 since we get audited for our compliance with the EU Medical Devices Directive and use compliance with 62304 to demonstrate that we meet the Essential requirements of this directive. If you are going to be audited then you will need a copy.
There are probably loads of regulatory forums but I like this one
[http://elsmar.com/Forums/forumdisplay.php?f=186|leo://plh/http%3A*3*3elsmar%2Ecom*3Forums*3forumdisplay%2Ephp%3Ff%3D186/uiqa?_t=tracking_disc]
where your questions may have already been answered. 62304 is less general than ISO9000 say since 9000 has to be accessible to a range of organizations. It is not totally prescriptive otherwise you could just do exactly what it says and regulatory consultants would be out of a job.. The approach to compliance depends on the size of the project etc.
Any more and I may have to invoice you… 🙂
Regards,
Steve

Erica Reid
Communications and Admissions Coordinator
Steven, do you think the ISO62304 is worth buying? I have another ISO document, and it is broad guidelines more than helpful info, I found. Thanks for the other info!

Steven Crook
Consultant Clinical Scientist (NHS) and Quality and Regulatory Manager (Medical Device company)
Hi Erica,
All the other responders are correct – give your coding and software development some documented structure. There is an international standard, ISO62304 that brings this all together and FDA also has guidance on how they want software validation presented for their reviews -e.g. 501(k).
[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm|leo://plh/http%3A*3*3www%2Efda%2Egov*3medicaldevices*3deviceregulationandguidance*3guidancedocuments*3ucm085281%2Ehtm/E-tB?_t=tracking_disc]
I’ve done a 510(k) a device with embedded microcontroller code where you hope you would have all the source code under control but we added a wireless comms component with a micro in so we have to validate the code/performance for that as well. FDA use the lovely term “SOUP” (Software Of Unknown Provenance) to describe these code modules.
Regards, Steve

Erica Reid
Communications and Admissions Coordinator
Thank you very much everyone, this has been very helpful!!

Brigid Glass
Coaching medical device companies to achieve regulatory quality management system compliance and improve their business
Erica, checking in on a question that you didn’t ask but might underlie the one you did ask. For all medical device design activities, and for software in particular, it’s important to have procedures in place, including what has been outlined above.

You must have your requirements and specifications clarified up front before coding starts. Otherwise verification and validation are very challenging. For physical aspects of a device, you can do this retrospectively (undesirable, difficult and morale-destroying, but possible, to an extent). For software, if you haven’t done this up-front, it usually isn’t even possible. Compliance requires traceability all the way through from inputs, through V&V.

Andrew Adams
Senior Manager of Medical Device Systems Engineering and Quality Systems Expert
I cannot list all the principal explanations for why one needs to do establish and use coding standards, but chief among them are software maintainability and understandability of the code. Coding standards, along with appropriate quality agreements for outsourced work that you may or may not have visibility into, help ensure that product complaint investigations can yield definitive answers at the software level without undue delay or expense. Such investigations support corrective and preventive actions while also improving the efficacy of debugging efforts and technical reviews.

In principle, you should contractually require suppliers to retain records of the software design and implementation for a suitable period to account for the potential need to conduct post-market activities. That is assuming they do not hand over the intellectual property.

I posted this because it is good to know what to do, but I believe it is better to know why to do it.

Eric Poole
Medical Device Software Development Consultant and Certified Scrum Master
If the coders (independent contractors or employees of an outside technical service firm) have their own written coding standard that meets the requirements listed above (peer-reviewed, approved by management of that technical service firm, follows generally-accepted guidelines for the programming language in use, and a mechanism is in place to review the output against the standard [thanks, Andrew]), then that coding standard can be used. Otherwise, the manufacturer needs to have one and require that the outside coders follow it.

Note that if, instead of an outside software development firm with its own organization, you just have a bunch of independent coders (independent from the manufacturer AND independent from each other), each of which has his own written coding standard that he/she follows, in theory that could be made to work but in practice it would be very difficult to show the FDA that the manufacturer has proper controls over the development process… somebody has to be centrally in control of (and responsible for) the software, and whoever that is should generate and control the coding standard.

My most recent project was as a contractor and software technical leader for a large medical device company. I recruited and hired a team of programmers, all independent contractors, and each with his own ideas about how to do things. I wrote the coding standard on behalf of my client, had it reviewed by my team and a couple of my client’s engineers, and required that the programmers all follow it. My client could have just as well written the coding standard and required that we all follow it, but they didn’t have the time or the resources to do that and so they delegated that to me.

Marty Nichols
Vice President Alternative Sites at Omni Orthopedics
How much does that change if you are a manufacturer and you go to outside coders for solutions? Does the manufacturer write and control the standards or does the software coders?

Andrew Adams
Senior Manager of Medical Device Systems Engineering and Quality Systems Expert
I agree with Eric. I would add that technical reviews should confirm that the coding standards are being followed.

Eric Poole
Medical Device Software Development Consultant and Certified Scrum Master
No. You should have a coding standard that was peer-reviewed and approved by engineering management in your company and follows generally-accepted guidelines for the programming language in use, and you need to follow that standard. But there is no specific standard that you’re required to follow to be FDA compliant.