Topics In Demand
Notification
New

No notification found.

Medical Devices Software Development - Taxonomy & Engineering Guidelines
Medical Devices Software Development - Taxonomy & Engineering Guidelines

November 8, 2019

5

0

It’s fairly well established that regulated industries have their variants of the software development life cycle. There are set of compliances, quality & regulatory guidelines to follow along with the implementing industry standard toolkits meant for that domain. While some are non-binding in nature and are recommendations, others are non-negotiable.

Medical Devices software has a direct bearing on the patient lives, safety and overall well being.

Being a regulated industry, core Medical Devices software development has its own nuances, lifecycle.

This article starts with taxonomy of Medical devices in US, notes some key standards used in development and then recommends some basic engineering guidelines for software development for medical devices.

We will not cover here specific aspects of Risk Management as this is core activity by itself and deserves separate attention in software development lifecycle. Risk Management in fact here is much more formal discipline in medical devices software development and weaves through all aspects of design and development

Medical Devices software development broadly follows IEC 62304 standard. Taking into considerations for launch in US market, the key compliance needed is FDA Design controls listed as a part of CFR 820.30

Each country has their own classifications for medical devices. Based on the risk assessment, likely benefits and the hazard it may cause to patients,  taxonomy for Medical Devices by FDA

Class 1 – Low Risk: Thermometer etc.

Class 2 – Medium Risk: Blood Pressure Monitor etc.

Class 3 – High Risk:  Heart pacemaker, surgical implants which deliver labelled drug etc.

There is no substitute for sound technical design, architecture, robust coding, QA, basic engineering rigor and overall experience (which includes UI/UX) in any software development. But there are some engineering guidelines strongly recommended for Medical Devices Software Development

Templates & Checklist: These form the bulwark of the development. Based on industry standard best practices and the engineering needs of the engagement these should be evolved in the inception phase.

Checklist for coding code review, release, documentation etc. and this list gets tailored for the engagement. These artifacts should get developed upfront with a genuine commitment from team to honor this in spirit.

Adherence to the checklist is the one of the key activities for the leadership in the engagement.

No rocket science here but these humble checklists do introduce standardization across a larger team and goes a long way in helping on the overall compliance.

Induction Plan:

A well-defined and structured induction plan detailing the ways of the working and expectations in software development is absolutely key here. This may stretch for a month, if required.

Too often the mistake is done that the technologist is given just given a week or so to get accustomed to code base and with short knowledge transfer is put on the job. This does not prepare the individual in any way on what to expect to deliver core medical devices software.

Sensitivity needs to be drilled down to the person that his activity can directly impact patient’s lives and wellbeing.

Sharp Focus on QA Automation:

Software development plan and efforts must factor a high % of automation of test cases. In some projects which involve software for Class 3 Medical devices, 90% and above automation can be the norm.

Considering that significant efforts will go in functional testing and the sheer number of conditions that can come up, having a high % in QA Automation is well worth the efforts.

Documentation:

Accept it, developers hate to document things. See a problem, just fix it fast and move ahead. Why spend precious time in documenting things?

But right documentation is an absolute must for Medical Devices software development. These all form part of evidence to the regulatory authorities .For example during code reviews, if there is a need to change some aspect of code, the steps need to be documented. Overall flow should capture reviewer who did the reviews, the standards referred by reviewer, changes done in the code, functional testing followed post the change, results of automation needs to be documented so that traceability can be maintained.

 

 


That the contents of third-party articles/blogs published here on the website, and the interpretation of all information in the article/blogs such as data, maps, numbers, opinions etc. displayed in the article/blogs and views or the opinions expressed within the content are solely of the author's; and do not reflect the opinions and beliefs of NASSCOM or its affiliates in any manner. NASSCOM does not take any liability w.r.t. content in any manner and will not be liable in any manner whatsoever for any kind of liability arising out of any act, error or omission. The contents of third-party article/blogs published, are provided solely as convenience; and the presence of these articles/blogs should not, under any circumstances, be considered as an endorsement of the contents by NASSCOM in any manner; and if you chose to access these articles/blogs , you do so at your own risk.


© Copyright nasscom. All Rights Reserved.