0% found this document useful (0 votes)
82 views30 pages

Introduction To Software and Medical Devices

Uploaded by

Ofiter90
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
82 views30 pages

Introduction To Software and Medical Devices

Uploaded by

Ofiter90
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 30

Introduction to software and

medical devices
Quiz – What is software and what makes it
different?
1. The majority of software errors can be traced back to:
Users not reading the instructions for use
The manufacturing process
The design and development process
Insufficient testing

2. Why are software failures (bugs) different from failures in


hardware?
A software bug can always be traced to failures in a compiler
The probability of a software bug is not predictable
The probability of a software bug is predictable
A software bug can always be traced to incorrect usage

3. What role does the manufacturing process play in software


development?
In-process controls can be used to catch software failures
overlooked in software testing.
The manufacturing process can be used to improve software
usability.
Manufacturing is a good time slot for software validation.
The manufacturing process does not play any role in software
development.

4. A software development team wants to create high quality


software. What should they focus on to achieve their goal?
Concentrate on a good problem resolution process
Develop the software by strictly following the waterfall process
Concentrate on testing to preventing bugs from slipping through
Establish a good software design and development process

5. What makes software failures (bugs) challenging?


Extensive usage can wear out software and cause bugs
Software failures can cause more harm than hardware failures
Software comes with bugs which may not be detected before
releas
You always get a warning of failure in advance

6. Which aspect should you typically consider when developing


an app?
Operating systems to be supported
Battery charge time
The manufacturing process is different from other software
product
Network operators

Quiz – General software terminology


7. How can hardware become a limiting factor for the software
development of an app?
You must have different computers for developing Android and
iOS apps
Mobile phones come with different screen resolutions which may
impact the software design
The servers used for distribution can cause slow downloads

8. A sandbox for software development is a:


Shadow setup of a real product and used for prototyping
Temporary storage location for released apps before they
become available in App Store or Google Play
Software environment used in user validation
Nick name for software testing under design control

9. A compiler:
Reviews source code in search for errors
Translates source code into binary code
Converts source code between different programming languages
Is used to compile software documentation

10. How do you choose the programming language when


developing a medical device?
You choose a pre-approved programming language from the FDA
guidance on software development.
Programming language is chosen based on the product to be
developed and available skill sets.
You consult a notified body or similar authority to get guidance.
The software safety classification determines which programming
language to use.

11. You need to have an understanding of hardware to


develop software because:
A slow PC used for compilation can result in poor software
performance.
Development servers need to have sufficient storage space to
accommodate the development history.
Software performance can be limited by hardware, for example,
a slow memory.
12. What should you keep in mind when using a sandbox
for software development?
A sandbox is not expected to be under formal control
A sandbox is useful to create evidence for your design
verification
A sandbox is a nick name for software testing under design
control
Using a sandbox should be avoided

Quiz – Introduction to the regulatory


landscape
13. Do you meet all regulatory requirements if you fulfil
the requirements of applicable standards?
Yes, when complying with international standards you also meet
all regulatory requirements.
No, there might be additional regulatory requirements not
covered by standards.

14. When developing a medical device, you must meet


applicable regulatory requirements. But why should you
consider using standards?
Regulations require you to follow specific standards
The use of standards is a way to make sure all international
regulations are met
Regulators approve standards and consequently, standards
satisfy all regulatory requirements
Standards can provide means to meet regulatory requirements

15. What is IMDRF?


An international organisation with medical doctors who strive to
improve medical device safety
An organisation which assures that regulations are the same in
the EU and US
It is a global initiative where regulators strive to harmonize
regulatory requirements
A global organisation reviewing international standards before
they are published

16. A standard is:


A regulatory approved document
Considered to be an industry established practice
Mandatory to comply with regulatory purposes
Always best practice
17. What should you do to meet most regulatory
requirements when developing a new medical device?
Define a high-level requirement that regulatory requirements
shall be met
Follow applicable standards and guidance documents throughout
the development work
Invite regulators from applicable countries to audit the design
documentation
Submit a technical file to IMDRF for review and approval

Quiz – Introduction to classification of


medical devices and software
18. A SaMD categorisation is different from level of
concern and software safety classification because:
SaMD addresses stand-alone software which the others do not.
SaMD categorisation is defined by IMDRF and is therefore
acknowledged by all regulators.
There are no differences, they are all the same but use different
words.
SaMD categorisation takes two factors into account, significance
and situation, the others are mainly based on a single factor which is;
injury.

19. The medical device classification determines the


software safety classification.
False, they are different, for example, a high-risk medical device
can have low-risk software.
True, because software safety classification A, B and C are linked
to medical device classes 1, 2 and 3

20. SaMD categories can provide guidance on:


Determining software safety classification
Defining the correct level of concern
The potential harm a software can cause
MDR device classification for software-only products

21. The purpose of the software safety classification is to


determine:
Software severity in ISO 14971
Level of concern in a 510(k) submission
The rigour of the requirements in IEC 62304
How safe the software will become when working with IEC 62304

22. Is the FDA level of concern identical to software safety


classification? Select all correct answers.
No, the level of concern is based on the level of concern raised
by users of similar products.
No, level of concern is used to determine documentation in a
submission. Software safety classification is used to determine process
rigour.
Yes, they are identical even if the wording differs.
No, they use different words for the classification which can
result in different classification outcomes.

23. It is not mandatory to do an IMDRF SaMD classification,


but why is it still wise to do so? Select all correct answers.
It can be used as an alternative to software safety classification
according to IEC 62304
The categorization is used in a useful EU guidance on clinical
evaluation of SaMD
With the help of a MDR guidance document, it can be used to
determine device classification in the EU
It defines controls in change control and problem resolution for
the continued use of the software

Quiz – IEC 62304 in relation to other


standards
24. Which statement best describes the difference
between a process and a product standard?
A process standard is mandatory, a product standard is
voluntary.
A product standard describes “how to work”, whereas a process
standard defines requirements on the product.
A product standard is mandatory, a process standard is
voluntary.
A process standard describes “how to work”, whereas a product
standard defines requirements on the product.

25. Which of the following are often referred to as


management standards? Select all correct answers.
ISO 14971 – Risk
IEC 82304-1 – Health software
ISO 13485 – Quality
IEC 62304 – Software lifecycle processes

26. IEC 62366-1 is a usability engineering standard. Which


of the following best describes its relation with software?
It is only applicable to tangible products, not software
Only software with graphical user interfaces must consider the
standard
It is related to the usage of software, including for example
installation, and therefore applies to most software
Applicable to all software, if the risk assessment indicates user
related risks
27. For the US market, the IEC 62304 standard is:
Is not recognised by the FDA
An FDA-recognised consensus standard
Not applicable, you must follow applicable FDA guidance
documents

28. The medical device software life cycle standard IEC


62304 is a:
Risk management standard
Management standard
Product standard
Process standard

29. What is the purpose of the software standard IEC


82304-1?
It is an alternative standard to IEC 62304 which can be used for
standalone software.
It is a quality system standard for software development.
It describes how software is integrated into health hardware
products.
It is a product standard for health software products.

Quiz – The gap between IEC 60601-1 and


IEC 62304
30. The standard IEC 60601-1 is about general safety and
performance:
And is applicable to software when the software is included in a
medical electrical equipment
And is, therefore, applicable to all types of medical device
software
And is applicable to software when the software is included in
any electrical hardware
When working with medical electrical equipment and it is
therefore not applicable to software

31. The deliverables resulting from implementing IEC


62304 meet all requirements in IEC 60601-1 clause 14
(PEMS).
Yes, IEC 62304 is a process standard developed to meet the
requirements of IEC 60601-1
No, requirements related to validation are not covered by IEC
62304
Yes, the terms are different, but IEC 62304 provides full coverage
No, software verification is missing in IEC6 2304

32. IEC 60601-1 defines essential performance as:


Performance necessary to achieve freedom from risk
Performance necessary to achieve essential functionality
Performance necessary to achieve freedom from unacceptable
safety
Performance necessary to achieve freedom from unacceptable
risk

33. “Essential performance” and “safety” are both


important terms in IEC 60601-1. How does IEC 62304
address the two?
“Fail-safe functions” is an important term in IEC 62304
IEC 62304 mainly focuses on “essential performance”
The terms are equally important in IEC 62304
IEC 62304 mainly focuses on “safety”

34. Which of the following statements correctly explain the


differences between IEC 62304 and IEC 60601-1?
IEC 62304 is intended for stand-alone software only, for
embedded systems you shall choose IEC 60601-1
IEC 60601-1 allows you to have risk control measures outside of
your software, this is not allowed in IEC 62304
IEC 62304 is a process standard, IEC 60601-1 is a product
standard

Quiz – IEC 82304-1 – A product standard for


health software
35. Which of the following are considered accompanying
documents according to IEC 82304-1? Select all correct
answers.
Operating instructions
Verification records
Installation documentation
Requirement specifications

36. The IEC 82304-1 standard:


Is a product standard applicable to stand-alone software
Is a general standard applicable to all types of software
Defines requirements for validation of embedded software
Is an alternative to IEC 62304 when working with apps

37. The meaning of validation in the context of IEC 82304-1


is to:
Validate that all software development activities have been
conducted according to applicable plans
Validate that the software meets established use requirements
Validate the performance of the software development process

38. IEC 60601-1 and IEC 82304-1 are both product


standards relating to software. The standard IEC 82304-1 is
intended to be used when developing:
Software using high level programming languages
Stand-alone software (SaMD)
Embedded software
Large software systems

Quiz – Introduction to risk


39. What should come after determining “sequence of
events” when performing risk analysis?
Harm
Hazardous situation
Hazard
Severity

40. Software risk management main focus is on:


Changing the established software safety classification
Reducing the severity of harm
Reducing the likelihood of the harm occurring (P2)
Reducing likelihood of the hazardous situations occurring (P1)

41. In software risk management, you shall assume that


software failures always occur, but what does it mean?
Po shall initially be 100%
P2 shall be 100%
P1 shall initially be 100%
P1 shall be 100% throughout the life-cycle

42. Probability of occurrence of harm (Po), can be divided


into two components; P1 and P2. What is P1?
The likelihood of a hazard becoming a hazardous situation
The likelihood that harm can occur from a hazardous situation
The likelihood that the software fails
The likelihood that a hazardous situation results in a given harm

43. What should come after “Hazard”” when performing


risk analysis?
Severity
Hazardous situation
Sequence of events
Harm
44. Probability of occurrence of harm (Po), can be divided
into two components; P1 and P2. What is P2?
The probability of harm after risk control measures have been
implemented
The probability of a hazard becoming a hazardous situation
The probability that harm can occur from a hazardous situation
The probability that a hazardous situation results in a given harm

Introduction to IEC 62304


Quiz – Scope and general terminology
45. When refining an architecture, items are divided into
units. How many units are expected from each item?
One unit for each risk control measure in the item
For software safety class A and B, at least one unit and for class
C, at least two or more units
It can be any number. If an item is not refined, it becomes a
software unit itself
A software item must be split into at least two units

46. A software system is an “Integrated collection of


SOFTWARE ITEMS…” How should a software item be
defined?
A source file is equal to a single item
Each software requirement represents an item
It can be any identifiable part of a computer program
The size of an item is determined by the project plan

47. According to IEC 62304, a SOUP is defined as:


An existing software item for which adequate development
records are not available
An existing software system for which adequate development
records are not available
A new internally developed software item for which adequate
development records are not available
A new externally developed software item for which adequate
development records are not available

48. Which life-cycle phases does the IEC 62304 apply to?
Select all correct answers.
Pre-study
Development
Maintenance
Concept

49. There are many types of software, for example;


firmware, embedded software, SaMD, web service. What
type of software is in scope of IEC 62304?
Only software that is to be included in a physical medical device
Any software with a medical purpose except firmware because
that is considered to be hardware development
Any software that is part of a medical device or a medical device
itself
IEC 62304 is a software standard and thus only applies to stand-
alone medical device software, SaMD

50. For which of the following should the IEC 62304 be


applied to development and/or maintenance? Select all
correct answers.
Printer software used to print medical device labels
Software which is embedded in a medical device
A medical device which consists of a web service and an app
Tools used in a quality management system

Quiz – Development process and compliance


51. What software development process can be used to
comply with the requirements of IEC 62304?
Only a V-model based development process can be used
You are required to use a waterfall-based development approach
Any development process that has regulatory approval
Any development process that meets the requirements

52. According to the instructor of the course, a


“compliance checklist” can be a valuable tool to
demonstrate:
That all software system requirements have been implemented
How a development process implements a standard
Test coverage during software system test
How good employees comply to internal procedures

53. Agile development principles for medical software


development can be used for:
It should not be used at all when developing medical device
software
Prototyping software but not for the final medical device software
Only stand-alone software, it is not possible to use for embedded
software development
All types of software; it can be used as any other development
method

54. Requirement management can be done in many ways.


The requirement on software requirements in IEC 62304 is:
Requirements shall be established and verified before they are
used for design activities.
Requirements shall be defined before any design activities can
start.
Requirements shall be documented before software system tests.
Risk-based requirements shall be established before any design
activities can start.

55. The technical report TIR 45 provides guidance on


developing medical device software when working with:
Agile development
Test-driven development
Software as medical device, SaMD
Risk management activities
Quiz – Software safety classification
56. In what way does software safety classification
influence software risk management?
It can be used to identify risk control measures.
It determines the rigour of software risk management.
It is used to determine how safe the software is.
It is used to evaluate the effectiveness of risk control measures.

57. You can lower a software safety classification by


introducing hardware risk control measures, what more can
you do? Select all correct answers.
Improve your software development process
Remove functionality that is associated with risk from the
software
Add risk control measures to the software system
Leverage a different and independent software system

58. If the benefits of a medical device are great, a lower


software safety classification is acceptable because the
benefits outweigh the risks.
True
False

59. What document requires you to establish a software safety classification?


ISO 14971 Application of risk management to medical devices
FDA Software guidance documents
IEC 62304 Software life-cycle management
The MDR Annex VIII

60. Why is it valuable to determine correct software safety


classification early?
It is used to determine if the software is a medical device.
Class C is the default classification. If a lower classification
applies to your software, you can save time and money.
Class A is default. If you later find out a software belongs to a
higher classification, you must re-start the project.
It is used to determine appropriate development tools.

Quiz – Legacy software


61. When working with legacy software, the purpose of
“Gap closure activities” is to:
Postpone evaluation of missing deliverables
Plan how and when missing deliverables shall be generated
Retrospectively create a software development plan
Document why it is acceptable to not apply IEC 62304 for the
rest of the legacy software life-cycle

62. What is the legacy clause intended to be used for?


Select all correct answers.
For already developed products, which due to functional growth
become medical devices
It is an alternative way to comply with the standard and it allows
you to retrospectively document a new product development project
To fill the gaps if documentation is missing for new product
development projects
For existing products that get re-classified as a result of
regulatory changes
63. Legacy software and SOUP both refer to software that
is not developed according to the IEC 62304. What makes
them different?
SOUP is an FDA validated version of legacy software.
Legacy software applies to a software system, SOUP applies to
individual software items.
SOUP is developed internally, legacy software is developed by
others, such as open-source code.
SOUP applies to a software system, legacy software applies to
individual software items.

64. In which cases is it possible to claim that medical


device software is legacy software? Select all correct
options.
If you develop a new product and before launch discovers it is a
medical device
When a contractor, without knowledge of IEC 62304, develops a
new product
If a regulatory change re-classifies products, an existing non-
regulated software can suddenly become a medical device
If a non-medical device software is already on the market but
new functional growth makes it a medical device

65. Why is it valuable having access to post-market


information when bringing a legacy software into
compliance with IEC 62304?
Real use data is available for your risk management activities
It documents your software is safe to use, thus Class A
It can be used to justify limited software system testing
You don’t have to establish a software safety classification

Software risk management


Quiz – Understanding software risk
management
66. Which alternative below best describes what options
you have when it comes to implementing risk control
measures when developing software?
Not many, the only option is to implement risk control measures
in the source code.
Risk control measures for software can only be implemented by
hardware.
Risk control measures for one software system must be
implemented by a different redundant software system.
Software risk control measures can be implemented in several
ways, such as software development process activities, architectural
design and in the source code.

67. Software risk management focuses on reducing the


likelihood of a hazardous situations occurring, this
probability is often referred to as:
Po
P1
P2
S

68. Combining multiple software risk control measures can


reduce the likelihood of software contributing to hazardous
situations to zero.
False
True

69. Software risk management focuses on reducing the


likelihood of the software contributing to:
Hazards
Sequence of events
Hazardous situations
Harm

70. Which of the following can be used as risk control


measures to reduce software risks? Select all correct
answers.
Risk control measures implemented in software to mitigate
software causes
Risk control measures implemented by software to reduce risk
external to the software
Functionality in hardware which can limit the consequences of
software failures
A good software development process

Quiz – Development process as risk control


71. The requirement in IEC 62304 to “verify software
requirement” is often misunderstood as tedious and
bureaucratic but properly done, it is a value adding activity
because:
Well-understood requirements reduce business risks
It increases the likelihood of delivering on time and budget
High quality requirements facilitate a safe design
A good verification will reduce the number of requirements and
simplify the design work

72. A coding guideline is a valuable tool in a software


development process because it reduces:
Risks of mismatch between source code and regulatory
documentation
The need for requirement verification
Risks of misunderstandings between programmers
The need for test planning

73. A development process can be used as a risk control


measure. What should you do if you later discover bugs in
your software?
Follow the process and release a patch for every bug
Evaluate the bugs and improve your development process
Recall the software since the risk control measure failed
Increase your test efforts
74. Regression testing is a reduced test activity; but it is
wise to always repeat a full test of:
Hardware interfaces
Performance requirements
Risk control measures
User interfaces

Quiz – Software risk management in IEC


62304
75. With the activity “Analysis of software contributing to
hazardous situations” you are expected to establish a link
between hazardous situations and:
Severity of the hazardous situation
Software items
Software system
Source code files

76. It can be convenient to assign items to different


software safety classifications but how can it become a
challenge when implementing risk control measures (RCM)?
Class A items must be duplicated to safely implement RCM
Only Class C items can implement RCM
Items might need up-classification to match the RCM
RCM can only be implemented in units belonging to the highest
class
77. Why is removing unnecessary features a good safety
risk control measure?
Fewer requirements means more time do better design
It results in reduced traceability documentation
Reduced functionality means less code that can go wrong
It increases the likelihood to deliver on time

78. Which answer below best describes the traceability of


software hazards as required by IEC 62304?
Hazardous situation => software item => severity => risk control
measures => verification
Hazardous situation => harm => severity => risk control measures
=> verification
Hazardous situation => software item => software cause => harm
=> verification
Hazardous situation => software item => software cause => risk
control measures => verification

79. According to IEC 62304, which activities are expected


to be included in a software risk management process?
Select all correct answers.
Identification of hazardous situations
Identification of causes contributing to hazardous situations
Definition of risk control measures in the software
Identification of hazards

Quiz – Software causes


80. When working with software risk management, a
graphical user interface (GUI) is often a good place to start
looking for potential software causes. Which of the below
are software causes? Select all correct answers.
Information can be hidden by overlaid notifications
Users perceive the GUI unattractive which causes the software to
be used less than intended
GUI are often subject to changes which may cause delays in
software development
Users cannot determine image orientation due to poor GUI design

81. According to IEC 62304, you shall identify software


causes which can contribute to hazardous situations. How
many software causes should you identify per hazardous
situation?
At least one software cause for each hazardous situation
At least two to make the design single fault safe
To avoid complexity, never more than one
One software cause is enough, but you must use different causes
for different hazardous situations

82. In the context of software risk management; what is a


software cause?
A reason for how software can turn a hazardous situation into harm
A measure of how much harm a software can cause
Another word for coding mistakes
Something that can cause a software item to contribute to a
hazardous situation

83. Performing range check on user entries can be a


meaningful software risk control measure but not always
effective. Why?
Additional functionality slows down the software performance and
can influence efficacy of delivered treatment.
To enable proper functionality, ranges must be broad and therefore
accept entries that may contribute to hazardous situations.
If entries are not accepted, the user must re-enter information which
delays patient care.
Invalidating user entries may stress the user and contribute to new
usability-related hazardous situations.

84. In what way can a power outage contribute to software


failures? Select all correct answers.
A user might not be aware that settings have been restored to start
values
Software unavailability causes treatment delays
Data can be lost causing the software to misbehave when power is
restored
You cannot access information from the software

Quiz – Software risk control measures


85. What options should you consider when working with
software risk control option analysis? Select all correct
answers.
Inherently safe manufacturing process
Protective measures in the manufacturing process
Inherently safe design
Information for safety and, where appropriate, training for users

86. According to the instructor, what is a “safe state”?


A bug-free software state
A state in which the device cannot cause harm or at least as little
harm as possible
When software without links to hazardous situations is executed
A project state, after verification, when it is proven that the
software cannot contribute to hazardous situations

87. What do you need to consider if you want to re-use a


software risk control measure?
To only use it once within the same software item
The effectiveness for every single situation
Nothing! A pre-verified software risk control measure is an asset
To only use it once within the same software system

88. When performing a software risk control option


analysis, which should be your first choice to reduce risk?
Use protective measures, such as access control
Inherently safe design, such as removing features
Provide information to the user, such as information screens
Add verification to the manufacturing process

Software planning
Quiz – Development planning
89. What is software verification planning expected to
define?
Specified test cases to verify all individual requirements
Unit test strategy
Deliverables requiring verification
Acceptance criteria for validation of the deliverables

90. How frequently do you have to update a software


development plan?
For Class A software, you don’t have to update the plan
The plan shall be updated after each verification
The plan shall be updated every time the design and development
plan is updated
The plan shall be updated as development proceeds, as appropriate

91. How can a software development plan be documented


while meeting the requirements of IEC 62304? Select all
correct answers.
Software development planning must be documented as a separate
document.
A software development plan can be a single document or divided
into several documents.
When using Agile methods, a documented software development
plan is not needed; it is an integral part of the development method.
A software development plan can be integrated in your design and
development plan.

92. When developing software for a medical device you:


Must have a development plan for medical device development, but
nothing specific for software development
Don’t need a software development plan if you are using agile
methods, because the development method is a plan in itself
Must establish a software development plan
Only need a software development plan for software which belong
to software safety class B or C

93. When using SOUP software, which aspects must be


included in the software development plan?
Supplier evaluation of the SOUP developer
None. Software development planning only applies to the software
you develop within your organisation
Second source alternatives for each SOUP
Configuration and risk management of SOUPs

94. What shall be included in software configuration


management planning? Select all correct answers.
How to implement software changes
How to update, review and approve documents
What to be controlled
When items are to be placed under configuration control

95. What must be included in a software development plan


according to IEC 62304? Select all correct answers.
The process to be used
The deliverables of activities and tasks
Responsibilities for the design of software units
Time and cost for the software development project

Quiz – Configuration management


96. What is a configuration item according to IEC 62304?
An item which is used to configure the software development
environment
An entity that can be identified in case of failure leading to serious
harm
An item that is identified as a source file
An entity that can be uniquely identified at a given reference point
97. What is a configuration item? Select all correct
answers.
Build environment
Software engineers
Sandbox environment
Documentation

98. A system configuration is defined as a:


Set of documents and their versions that comprise the software
system documentation
List of configuration items used to build the software system
Set of configuration items and their versions that comprise the
software system configuration
List of configuration items used to identify software system
documentation

99. In IEC 62304, “configuration status accounting” is


about retaining retrievable records of the history, such as
system configurations. This is crucial information in
software development because it:
Provides evidence that the software is not a legacy software
Can be used to identify responsibilities when anomalies are found
in the software
Enables release of updates/patches to older software versions
Is required to be documented by notified bodies, NB, in the US

100. For the purpose of identification of software


configuration items, the manufacturer shall establish:
A suitable file structure to identify configuration items
A scheme for the unique identification of configuration items and
their versions
Means to identify reviewer and approver of configuration items
An index that identifies software configuration items

Quiz – SOUPs – How to manage and


document
101. When developing medical device software, a developer
can choose to include OTS software. What is OTS software?
A software component developed by a contractor for which the
manufacturer cannot claim complete software life-cycle control
A generally available software system for which the manufacturer
cannot claim complete software life-cycle control
A software component which was developed prior to the application
of IEC 62304
A generally available software component for which the
manufacturer cannot claim complete software life-cycle control

102. Why are you required to specify functional and


performance requirements of SOUP item by IEC 62304?
To assess if you can develop the functionality yourself
It is used for SOUP supplier selection
To evaluate if the SOUP is needed
To safeguard correct SOUP execution

103. What can the origin of a SOUP be? Select all correct
answers.
A manufacturer providing general drivers for their hardware
components
A developer selling operating systems to be incorporated in all
types of products
A contractor developing selected software items
Open-source software projects

104. What should you consider when documenting


requirements for a SOUP? Select all correct answers.
Specify software requirements to enable proper SOUP execution
Specify hardware requirements to enable proper SOUP execution
Specify budget requirements to safeguard future maintenance
Specify requirements for used functionality of the SOUP

105. According to the FDA guidance about off the shelf


software (OTS), special documentation is required for:
OTS software where there is no established development process
Software which is a major level of concern after risk control
measures
Software which is minor level of concern before risk control
measures
Open-source software, not for commercial SOUPs

Software design
Quiz – Software requirements
106. Software requirements shall be traceable to:
Marketing requirements
System requirements or other sources
Regulatory requirements
The software engineer implementing each requirement
107. Which aspects should you consider when you perform
the activity “Verify software requirements”? Select all
correct answers.
All requirements shall be traceable to a risk control measure
Resource consumption when testing requirements
Requirements shall be traceable to a source
Requirements shall be stated in terms that permit establishment of
test criteria

108. According to the IEC 62304, when performing software


requirements analysis, it is a requirement to update:
The requirements to ensure that existing requirements, including
system requirements, are re-evaluated and updated as appropriate
The software development plan to fully reflect the project scope
And re-evaluate your project team and update the software
development as appropriate
And issue a new revision of both system requirements and risk
assessment

109. According to the IEC 62304, what is expected during


software requirement analysis? Select all correct answers.
Assigning requirements to appropriate items
Every requirement shall have a suitable test established
Risk control measures shall be included in the requirements
The medical device risk analysis shall be re-evaluated when
software requirements are established

Quiz – Software architecture


110. What are the documentation requirements for a
software architecture?
At a minimum; a flowchart describing all software units is required
At a minimum; a flowchart describing all software items is required
The documentation must be sufficient to facilitate verification of the
software architecture
An architecture document must include a sequence diagram
111. According to the IEC 62304, you can assign software
items to different software safety classifications compared
to the software system. In order to do so, what must you
consider?
You can only lower the classification on class, i.e. C=> B or B => A
Items of different classifications must be developed by different
programmers
Only hardware can be used to properly segregate items of different
classification
Assure proper segregation between items of different classification
112. According to the IEC 62304, interface requirements in
the architectural design shall be developed:
Only for the interfaces between software system and external
components
Only for the interfaces between internal software items
For internal interfaces, but external interfaces are not in scope
For the interfaces between software items and both internal and
external components

113. During a software architecture verification, you verify


that the medical device architecture supports proper
operation of any SOUP items. What more should you
consider when verifying the architecture?
That the architecture implements requirements including those
relating to risk control
That there is a balance in complexity and workload between the
defined software items
If the intended programming language is appropriate for the
planned architecture
That all software items are refined into software units

114. Does software architecture always have to identify the


necessary segregation for risk control?
Yes, it is required for all software safety classes.
Yes, because it is a regulatory requirement.
No, it is only required for class C software.
No, it is good practice but not a requirement in IEC 62304.

115. When designing a software architecture, how many


items are you expected to define?
A software system shall be refined into two or more items
If appropriate, a software system can be a single item
At least three items to enable separation between risk, SOUP and
requirements
No specific number expected but each external interface shall have
its own item

Quiz – Software detailed design


116. When developing Class C software, you must document
your detailed design, but how detailed shall it be?
It shall be enough to allow correct implementation
There shall be a functional description of all units
Detailed enough to support testing
Each unit shall have a defined requirements
117. Which of the following is applicable to Class C software
only?
Subdivide software into SOFTWARE UNITS
SOFTWARE UNIT VERIFICATION
Implement each SOFTWARE UNIT
Develop detailed design for each SOFTWARE UNIT

118. When verifying a software detailed design, you verify


that the design:
Is free from contradiction with the software architecture
Is testable
Implements all software requirements
Is under proper configuration control

119. The intent of detailed design documentation is to:


Enable thorough test planning
Explain functional details for external reviewers
Capture details necessary for proper implementation and
maintenance
Facilitate review for quality assurance (QA)

120. In the context of IEC 62304, what is a software


development team doing when they work on detailed
design?
Finalizing the software architecture
Detailing the development environment
Writing source code
Refining items into units

Quiz – Software unit implementation


121. Unit testing is valuable because it is:
Provides quantitative values to be used in estimation of probability
of occurrence
Often easier to verify details, like ranges compared to doing it at
the system level
Reduces the need for detailed design documentation
Removes the need for additional integration and system test

122. According to IEC 62304, “the manufacturer shall


establish strategies, methods and procedures for verifying
the software units”. Unit verification:
Must always include unit testing
Strategy can be different for individual units
Must be repeatable and should therefore avoid using peer-reviews
Shall be scripted to make it automatable

123. In IEC 62304, what are the requirements on


documentation of unit verification?
Each unit test shall be traceable to system requirements
All documentation defined by IEC 62304 shall be on paper and
approved accordingly
Only that it shall be documented, there are no further requirements
You shall comply with document control requirements found in ISO
13485 or QSR

124. According to IEC 62304, where unit verification is done


by testing, the test procedures shall be:
Approved by a software risk manager
Evaluated for adequacy
Performed by an QA department
Prepared by an independent test department

Software testing
Quiz – Software integration testing
125. If you chose not to perform dedicated integration
testing, what should you do instead?
If the software system is small, there is no need to do anything
instead
A risk assessment to assure that lack of integration testing does not
contribute to hazardous situations
Incorporate integration aspects in the software system test
Broaden the scope of software unit testing

126. Software “integration” and “integration testing” are


two different things. Which statements best describe the
two terms? Select all correct answers.
Integration combines software parts into larger building blocks
Integration testing tests functionality resulting from integration of
units
The purpose of software integration is to verify correct software
operation in the final product
Integration testing can be used to replace unit testing because
many units can be tested at the same time

127. According to IEC 62304 you are required to conduct


regression testing when working with previously integrated
software items because:
Previously integrated items can be outdated and must be re-built
New items can negatively affect previously integrated items and
introduce side-effects
All items must have an up-to-date integration test before entering
system tests
Regression testing tests previously untested functionality

Quiz – Software system testing


128. According to the instructor of the course, software
system testing is crucial to:
Improve poor design
Confirm the software is working as intended and is safe
Identify areas for improvements in the development process
Identify who made coding errors

129. If you correct bugs found during system testing, how


much do you need to retest? Select all correct answers.
Necessary tests to verify the effectiveness of the change
Software unit testing is sufficent, no need to repeat system testing
Everything, a system test must be complete
Enough to demonstrate that no new issues have been introduced

130. What is the purpose of evaluating software system


testing according to the IEC 62304? Select all correct
answers.
Identify test improvements in advance of the next software system
test
Determine how much identified problems will impact a project
timeline
Confirm that test results meet the required pass/fail criteria
Verify that all requirements have been tested or otherwise verified

131. When establishing and performing software system


testing, how many tests do you need to establish per
requirement?
Not more than one if there is a good software unit test established
Always two, one negative and one positive test case
One test per requirement is sufficent to provide required test
coverage
Usually more than one to cover combinations of conditions

132. In IEC 62304, “Evaluate software system testing”


expects you to verify that test results meet the required
pass/fail criteria, what more should you do in this activity?
Verify that tests are traceable to who conducted each test
Compare planned vs. actual time spent on software system testing
In case of failures, evaluate and document the root cause for the
failure
Verify that traceability between requirement and test is recorded

Software release and post


release management
Quiz – Software release
133. A software release shall be documented. When is the
latest point in time you must do it?
After a system integration resulting in product release
Every time you create a new release candidate
Immediately after a successful software system test
When the software is used in system integration

134. When is it acceptable to release software with known


anomalies?
Only if the probability of occurrence is acceptable
It is never acceptable to release a software with known anomalies
If a complete list of anomalies are provided in the release note
If anomalies are evaluated to not contribute to unacceptable risk

135. In a software release you shall document released


versions. What more are you expected to document?
Deviations to the software development plan
Remaining requirements to be implemented
Quality and regulatory approval of the release
Known residual anomalies

136. According to IEC 62304, software release is defined as:


The same as a design release
An input to system-level activities where it will be integrated with
other parts to become a design release
For software as medical device, SaMD, a software release is
equivalent to a design release
A binary package of the software suitable for delivery to end-users

Quiz – Maintenance plan


137. In software maintenance processes, when do you need
to communicate with both users and regulators?
When users can upgrade to a new software release
If the continued use of a released software version adds complexity
to the manufacturer's maintenance work
If the continued use of a released software version could contribute
to hazardous situations which may result in harm
If users find a software version difficult to use

138. In the context software maintenance planning, the


purpose of “Problem and modification analysis” is to do an
analysis of the feedback to determine if:
Feedback could have an impact on safety and what needs to be
done in the software
The user can be told to use the software differently through a field
safety notice
It is a problem and if yes; initiate a recall of applicable software
versions
Software system testing needs to be improved

139. From a safety perspective, why should you have a


proactive approach to software maintenance and not only
respond to received feedback?
It is good practice to re-release the software on regular basis to see
if software system testing can reveal new bugs
Regular updates are required to help users stay alert and minimize
the risk of routine handling
If the environment changes, such as new cybersecurity threats, a
software update may be required without received feedback
To keep the software “state of the art”, new user features must be
added regularly

140. From a software maintenance perspective, what is


especially important when working with SOUPs and
cybersecurity?
To include user concerns related to the use of open-source software
and the risk of being exposed to hackers
Establish a strategy to react to customer feedback related to SOUPs
and cybersecurity problems
Monitor anomaly lists published by regulators
Establish a strategy to proactively search for information related to
SOUPs and cybersecurity relevant for your software

Quiz – Problem resolution – the process


141. Which alternative is correct when it comes to
implementing a software problem resolution process?
If available, you must use existing complaint handling procedures in
your quality management system.
You can use different software problem resolution processes
depending on where you are in the development life-cycle.
If you are working with agile, there is no need for a documented
software problem resolution process.
It is sufficient to define a software problem resolution process for
problems occurring after release to intended users.

142. In conjunction with which activity does having a


problem resolution process become a requirement?
Unit test
Integration test
After release
System test

143. Why is it useful to classify problems when working with


software problem resolution?
It can be used to find opportunities for improvement in your
software development process
It should be used to choose a less error-prone programming
language
It simplifies annual reporting of software bugs required by
authorities
Because it can be used to identify weak programmers who need
more training

144. While developing new features, you encounter a


problem in software which is currently in use by end users.
You should register a problem report and:
Wait to fix it until customers reports the problem, customers might
provide additional information
Schedule it to be fixed in the next release
Investigate the problem to determine if customers and regulators
must be informed
Immediately inform customers to stop using the software until
further notice

Quiz – Change control


145. Risk management of software changes shall include an:
Assessment if the change needs to be communicated to regulators
Analysis of impact on existing risk control measures
Assessment if the change needs to be communicated to customers
Analysis of potential recalls resulting from a change
146. When working with software changes according to IEC
62304; what is the meaning of “provide means for
traceability of change”?
There shall be records of the relationship between change request,
relevant problem report and the approval of change request.
Changes shall be traceable to a customer request.
There shall be records of the relationship between change request,
software item and relevant verification.
Changes shall be traceable to a person requesting the change.

147. You only have to change configuration items in


response to:
An approved change request
Customer feedback
A registered change request
Updated requirements

You might also like