Feature Article

Developing Medical Device Software to IEC 62304

Posted in Medical Software by Brian Buntz on June 1, 2010

Medical software design standard IEC 62304 has just come into force. This article describes how it will impact the software development process for medical device manufacturers.

Standards for medical device design
Until recently, safety regulations for medical device software, at least formally, were not exceptionally rigorous across the board. In addition, software was not formally classified as a medical product by the Medical Devices Directive. This has now changed. A new regime is in force governing all medical device software development for all classes of device.
Previous software safety standards were best suited to medical devices with low levels of risk, as opposed to products where software failure could be extremely serious and result in death. As more electronic products have become dependent on embedded software, the focus has shifted to the reliability of software systems within the devices and the associated risks at all levels of usage. As a result, the new EN/IEC 62304 standard has emerged as a global benchmark for management of the software development lifecycle (Figure 1).
Risk analysis for hardware and software design
Medical product designers have used risk management techniques to help reduce the risks associated with device hardware. BS/EN/ISO 14971 has traditionally been adopted as the base standard for risk management for medical devices. The 2007 version of this standard is considerably extended from its previous version, and the techniques described are now intended to be applied to both software and hardware systems.
The approach that should be taken is to consider the risks posed by the medical device as a whole, before the software/hardware split has been decided. Hardware risk analysis can then run alongside software risk analysis to define the required safety systems for the device.
A harmonised standard
Figure 1: How IEC 62304 fits into the compliance process and its relationship with other standards.
IEC 62304 is a harmonised standard for software design in medical products adopted by the European Union and the United States. Because the standard is “harmonised,” medical device manufacturers adopting it will satisfy the essential requirements contained in Medical Devices Directive 93/42/EEC (MDD) with amendment M5 (2007/47/EC) as related to software development. This is the least onerous route to ensuring compliance with the MDD. US FDA will also accept ANSI/AAMI/IEC 62304:2006 as evidence that medical device software has been designed to an acceptable standard. This standard is identical to the EN/ISO variant in all essential details.
Designing to IEC 62304 ensures that quality software is produced by means of a defined and controlled process of software development. This process must contain a set of requirements based on the safety class of the software that is being developed.
Software safety classification
Initially the IEC 62304 standard expects the manufacturer to assign a safety class to the software system as a whole. This class-ification is based on the potential to create a hazard that could result in an injury to the user, the patient or other people.
The software is classified into three simple classes, as follows:
  • Class A: No injury or damage to health is possible
  • Class B: Nonserious injury is possible
  • Class C: Death or serious injury is possible
Defining “serious injury,” “nonserious injury,” “injury” and “damage to health” is important to apply this classification effectively. It may at first appear to be obvious what constitutes an injury; however, this can be a far more complex question when the context of the device is taken into account. Unfortunately the standard only defines “serious injury,” and this is as follows:
Serious Injury
Injury or illness that directly or indirectly
a) is life threatening,
b) results in permanent impairment of a body function or permanent damage to a body structure, or
c) necessitates medical or surgical intervention to prevent permanent impairment of a body function or permanent damage to a body structure.
Note: Permanent impairment means an irreversible impairment or damage to a body structure or function excluding trivial impairment or damage.
Figure 2: A safety-critical software system can be split into items, each one running on different processors and each with a different safety classification. 
It is relatively simple to apply a negative to the above to derive a nonserious injury definition. However, the definition of injury for use with the Class A software safety classification may be debatable. This is complex because of the lack of definition of injury or damage to health. For example, there may be a grey area involving the normal side effects of treatment of a condition as opposed to the device itself causing injury.
Procedures for carrying out this initial analysis and defining the class to be applied have been developed. In some cases, the notified body being used can affect this decision. Some will recommend that Class B is the minimum standard to be applied for any medical product, as the Class A safety classification does not insist on a sufficiently rigorous software development process.
There are major differences in the development process in terms of cost and time between a Class A and Class B code. It is therefore essential that medical device developers get this right at the outset. The safety classification also has a great impact on the documentation and process that is required.
Software items and units
Once the initial safety classification has been carried out for the system, it is possible to break the system down into software items and software units. These are defined as follows:
  • Software Item: “Any identifiable part of a computer program” [ISO/IEC 90003:2004, definition 3.14, modified]
  • Software Unit: “Software item that is not subdivided into other items” [ISO/IEC 90003:2004, definition 3.28, modified]
In practice, the software items can be any subsection of a system or its constituent parts. An architectural diagram is required to show the software items and software units. It is possible to then downgrade the safety classification of parts of the software system provided that these can be segregated. The note on section 5.3.5 of the standard gives an example of this segregation:
“An example of segregation is to have software items execute on different processors. The effectiveness of the segregation can be ensured by having no shared resources between the processors.”
In practice, this means that a safety-critical software system can be split into items, each one running on different processors and each with a different safety classification (Figure 2). Again, it is important to get this split correct at the outset to ensure that the system is safe and high quality, but also produced within the appropriate cost and time guidelines. Systems are available to analyse medical product software architecture and to define these items. Such processes can greatly reduce timescales and costs for the development of medical devices.
Table I: Summary of safety classification effects on the code development documentation and process.
Software Documentation Class A Class B Class C
Software development plan Must contain contents to sections 5.1 IEC 62304:2006. The plan's content list increases as the class increases, but a plan is required for all classes.
Software requirements specification Software requirements specification conforming to 5.2 IEC 62304:2006. The content list for the software requirements specification increases as the class increases, but a document is required for all classes.
Software architecture Not required. Software architecture to 5.3 IEC 62304:2006. Refined to software unit level for Class C.
Software detailed design Not required.   Document detailed design for software
units. (5.4).
Software unit implementation All units are implemented, documented and source controlled (5.5.1).  
Software unit verification Not required. Define process, tests and acceptance
criteria (5.5.2, 5.5.3).
Carry out verification (5.5.5)
Define additional tests and acceptance
criteria (5.5.2, 5.5.3, 5.5.4).
Carry out verification (5.5.5).
Software integration and integration
Not required. Integration testing to 5.6 IEC 62304:2006.
Software system testing Not required. System testing to 5.7 IEC 62304:2006.
Software release Document the version of the software
product that is being released (5.8.4).
List of remaining software anomalies, annotated with an explanation of the
impact on safety or effectiveness, including operator usage and human factors.
Impact of safety classification
The safety classification has a tremendous impact on the code development process. It is therefore in the interests of medical device manufacturers to get this right the first time to avoid expensive, time-consuming rework late in a project.
A brief summary of the effects of safety classification on the documentation and process is shown in table I. In practice any company developing medical device software will carry out verification, integration and system testing on all software classes. However, the difference is that formal detailed documentation does not need to be generated for Class A code. Cross-referencing and verification of requirements also does not need to be formally proven. This can save a great deal of time and money in software development.
Software of unknown provenance, or SOUP, is any code (tools or source code) that does not have formal documentation or was developed by a third party and has no evidence as to the controls on the development process. This code by definition is deemed to be capable of producing faults. It is important to carry out a software risk analysis on any SOUP code being proposed for the software under development and produce a rationale as to why this code should be used.
The use of SOUP is affected by the code safety classification. If the code is deemed to be Class A, then SOUP code can be used without further justification. As the class increases, the risks increase and the rationale becomes harder to justify. In practice this means that only simple function, well known and diversely applied SOUP code can be used for Class C applications.
A technology solutions provider specialising in electronics design and production services has developed processes to identify and justify the use of SOUP in medical device software. Its own experience with this has proved that such processes can drastically reduce development time-scales and costs. This is a route that medical device developers should incorporate into their design procedures.
IEC 62304 is a well considered, logical standard for developing safety critical and high reliability software for medical devices. Now that this standard has been adopted it would be very difficult for a medical device software developer to justify any equivalent approach that meets the requirements of the MDD, without effectively complying with this standard. This is good news for the safety of patients, but also for the manufacturers themselves, as the standard establishes a more level playing field. There is no longer any opportunity for uncontrolled rudimentary software development processes, and this raises quality across the board.
In addition, as IEC 62304 is a harmonised standard that has been adopted internationally, it tends to equalise quality expectations between Europe and the United States.
For medical device manufacturers, it is important that they select software designers who have well-established risk management systems, as they will already have the foundations in place to meet IEC 62304. Additionally, my professional experience has proved how valuable processes can be to analyse medical product software architecture and usage. Such processes can greatly reduce timescales and costs for the development of medical devices. 
Ken Hall
is Technical Director at Triteq Ltd,
3 The Courtyard, Stype, Hungerford,
Berkshire RG17 0RE, UK
tel. +44 1488 684 554
e-mail: ken.hall@triteq.com


Related stories

Simplifying IEC 62304 Compliance for Developers

Decoding MISRA C:2012 for Medtech Applications

Find more content on:
Your rating: None Average: 4.5 (2 votes)

Login or register to post comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I recently found many useful

I recently found many useful information in your website especially this blog page. Among the lots of comments on your articles. Thanks for sharing.
do my essay for me

Great article Lot's of

Great article Lot's of information to Read...Great Man Keep Posting and update to People..Thanks

Mmm.. good to be here in your

Mmm.. good to be here in your article or post, whatever, I think I should also work hard for my own website like I see some good and updated working in your site.
mississauga web design

Thanks for a very interesting

Thanks for a very interesting blog. What else may I get that kind of info written in such a perfect approach? I’ve a undertaking that I am simply now operating on, and I have been at the look out for such info.
man made diamonds

I am always searching online

I am always searching online for articles that can help me. There is obviously a lot to know about this. I think you made some good points in Features also. Keep working, great job!
X431 V

Great post full of useful

Great post full of useful tips! My site is fairly new and I am also having a hard time getting my readers to leave comments. Analytics shows they are coming to the site but I have a feeling “nobody wants to be first”. seo service

Nice blog and absolutely

Nice blog and absolutely outstanding. You can do something much better but i still say this perfect.Keep trying for the best.
isolatie vloer PUR

thank you, the information

thank you, the information presented on this website really helped me in understanding the development of the world, especially in the field of Developing Medical Device Software to IEC 62 304 Jual Crystal X Asli Nasa

I am hoping the same best

I am hoping the same best effort from you in the future as well. In fact your creative writing skills has inspired me.
medical insurance Dubai

Your post had provided me

Your post had provided me with another point of view on this topic. I had absolutely no idea that things can work in this method as well. Thank you for sharing your opinion. obat wasir obat gondok obat jantung koroner

I think the actual approach a

I think the actual approach a person produce might appear including buying a lot attention therefore you acquire put it in a very way anyone can fully grasp. Must take pleasure in the actual good post you've got constructed the subsequent. electrocardiografos

Thanks for the blog loaded

Thanks for the blog loaded with so many information. Stopping by your blog helped me to get what I was looking for.

I like the valuable info you

I like the valuable info you provide in your articles. I will bookmark your blog and check again here frequently. I am quite certain I will learn many new stuff right here! No Win No Fee

This is really a nice and

This is really a nice and informative, containing all information and also has a great impact on the new technology. Thanks for sharing it,

Wow, wonderful blog layout!

Wow, wonderful blog layout! How long have you been blogging for? you make blogging look easy. The overall look of your web site is fantastic, let alone the content!
custom writings

Thanks a lot for sharing us

Thanks a lot for sharing us about this update. Hope you will not get tired on making posts as informative as this. watch movies online in theaters

The 2007 version of this

The 2007 version of this standard is considerably extended from its previous version, and the techniques described are now intended to be applied to both software and hardware systems.
serrurier paris 9

I really like the dear

I really like the dear information you offer in your articles. I'm able to bookmark your site and show the kids check out up here generally. Im fairly positive theyre likely to be informed a great deal of new stuff here than anyone else!
fire hose testing procedures

The approach that should be

The approach that should be taken is to consider the risks posed by the medical device as a whole, before the software/hardware split has been decided
Hotel in Stuttgart

There are various innovation

There are various innovation been done, how medical facility works even more sophisticated with the use of technology in order to facilitate many health care issues. Many of them are actually doing so, and even beyond what is expected, like today, some medical devices software are working with certain electronic device that is always with us in our day to day living, the smartphone. Like the http://www.interactivecare.ca/, which is expert in innovating mobile health software that will works in any mobile platform.

thanks for the info,

thanks for the info, Ciri-ciri Kemasan Terbaru Crystal X Asli Nasa Jogja this information really helped me in knowing how far way Developing Medical Device Software to IEC 62 304, especially in the current surgical device is needed to improve patient care Distributor Resmi Crystal X Asli NASA Yogyakarta

Thank heavens, another

Thank heavens, another solution idea can be a technique for neutralizing these kinds of behaviour. Unlike handle it will likely be primarily based created for appointed possessing bamboozled about the without having which frequently experts keep amounts to just without having drug treatments. pool cleaner reviews

de Recherche dans Video m’a

de Recherche dans Video m’a conduit ici, je viens de trouver ce genre de lectures satisfaisante que je cherchais for. pdf to flash converter | pdf to word transfer s

Medical device software

By the help of advanced and modern medical device software; medical experts are liable to deliver quality health care opportunities to the people. Especially in different medical care organization and centers; we have found the use of medical software for developing the current medical care and treatment service in our society.

It can be the great case to

It can be the great case to learn more about these development tips.


Developing medical software for medical records or for the management in medicines is really one of the best things to reduce the tension of keeping all the records manually in files that are handled repeatedly. IT people who know how to build simple and easy to understand software that is helpful for doctors is worth finding. I assigned one team of IT’s to build an online physical therapy software and they did a great job in fulfilling our needs.

Minneapolis, MN

For IEC 62304, the Quality Management System (QMS) assessment consists of the manufacturer’s software development and maintenance, configuration management, risk management, verification, and validation. These areas need to be assessed by a Notified Body that has strong technical expertise in medical device software as well as all of the processes outlined in IEC 62304.

MN Designers

Medical s/w

IEC 62304, if accepted, requires what reputable medical device manufacturers are already doing...
Ref: best Customer care
best Customer care

This is great that in these

This is great that in these days IT sector helping the medical field with their highly advanced software. Wordpress Theme Customization

Absolutely, you are right.

Absolutely, you are right. Computerize work are much better than manual. Developing software is really a big help for them especially when handling huge records. -buy instagram followers
Click Here

I am totally agree with you

I am totally agree with you that today's IT field helping the medical department with their wonderful software which helps in their medical practice for doing surgeries and finding problems.
Service for Mobile Field

This needs more technologies

This needs more technologies and techniques for good improvement.
John@ Minneapolis Web Designers

Developing Medical Device Software to IEC 62304

The International Electrotechnical Commission created the IEC 62304 standard. The standard, formulated to govern the requirements for medical software...
Ref: pallet racking
pallet racking

Medical Software

I agree with Amiston, medical software must be given extra attention as what can happen inside an institution, hospital for instance, would greatly depend on this, although if a software is a success tech PR agencies in London can easily promote the software to UK's medical institutions. Client's information must be sec ured, and if it can also provide a filtered information and people who can access it (barcode IDs) that would also be beneficial. Software malfunction can place a patient's life on risk, hacking of information - changing med's name/dosage can also be critical. Patient's information can also be use for medico-legal, therefore it should have the capacity to save the original input, changes and time & date in the information.

So from what I understood the

So from what I understood the software items can be any of the subsections of the system? Or even of its constituent parts? If it's possible to downgrade the safety classification of parts of the software system that was provided, then I would recommend the data center hosting system. Without this kind of system most businesses lack especially the security measures and even the infrastructure.

Implementation with ROI as guidance

The process as some of the above comments indicate could turn into a box ticking, but what i would take away and like to see it implemented in my company is

1. Identify and Define the class of the product based on SW driven hazards.

2. With this as the plan i would like to use Table 1 as a reference with ROI in mind for each step.

3. Then basically strengthen enough my architectural view points to ensure fault mitigation and unintended affect/hazards are cleared out.

On a parallel note, it would be good to invest and see if there is a pattern model that could be developed to address the fault tolerant design methodology.


This standard, whilst soundly based, makes software engineering into a box-ticking discipline. For the consumer-targetted medical devices which my company markets, the additional bureaucracy multiplies the resources required for no benefit to anyone. There is no substitute for good design and test but standards such as this tend to generate a complacent approach in which managers may feel the code is good because the standard has been followed. Not true.


Creating software for medical devices is a tricky and risky business. You have to get every line of code perfect and everything else about it , even the have to be just perfect. Just think if the software was to malfunction it could cost someone a life.

ISO 62304

ISO 62304 should be IEC 62304:2006. This standard is as EN 62304:2006 already in the MDD harmonised standards list since 2008/11/27. So the claim "has just come into force" is not quite accurate.