DESIGN
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 constitu-
ent parts. An architectural diagram is
required to show the software items and
software units. It is possible to then down-
grade 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.
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 documenta-
tion and process is shown in table I. In
practice any company developing medical
device software will carry out verifica-
tion, 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 for-
mally proven. This can save a great deal of
time and money in software development.
SOUP
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
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 ISO 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 ISO 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 ISO 62304:2006. Refined to software unit level for
Software detailed design
Not required.
Document detailed design for software
units. ( 5. 4).
Software unit implementation
Software unit verification
Software integration and integration
testing
Software system testing
Software release
All units are implemented, documented and source controlled ( 5. 5.1).
Not required.
Document the version of the software
product that is being released ( 5. 8. 4).
System testing to 5. 7 ISO 62304:2006.
Check and release according to 5. 8 ISO 62304:2006.
List of remaining software anomalies, annotated with an explanation of the
impact on safety or effectiveness, including operator usage and human factors.
