Miika Pietilä

IVD compliant software development

process

Metropolia University of Applied Sciences

Master of Engineering
Information Technology
Master’s Thesis
23 January 2023
PREFACE

This thesis includes a study on how non-regulated software development process

can be migrated to be used in regulated medical device and laboratory device
environments. The subject of the thesis is near to what I do in day-to-day work.
However, it is also something that there is never enough time to really allocate time
and focus so this was a good opportunity to study the subject deeper.

There were many challenges during the research work and the biggest challenge
was to allocate time for the research and that of course the time came mostly from
my spare time. Second challenge was to interpret all the material introduced during
the overall research. Regulations and standards leave a great deal of room for
interpretation and how different requirements can be utilized in the target software
development environment.

There were several things I learned during the thesis work. How to analyse source
material from more than one perspective, how to incorporate and view requirements
and standards from stakeholder’s points of view and how to gather this information to
understandable and clear structure to be shared and to be used in future process
development. In the end the overall thesis and report were success and customer
were really satisfied with the results and future development opportunities.

I would like to thank my supervisors and stakeholder group for helping me to get the
research work and thesis done and finalized and especially thank my family for
dealing with long nights and weekends upstairs.

Hyvinkää, 23 January 2023

Miika Pietilä
Abstract

Author: Miika Pietilä

Title: IVD compliant software development process
Number of Pages: 56 pages + 3 appendices
Date: 23 January 2023

Degree: Master of Engineering

Degree Programme: Information Technology
Professional Major: Medical Technology
Supervisors: Timo Kärmeniemi, R&D Manager
Mikael Soini, Principal Lecturer

Customer was developing software for a non-regulated general laboratory devices

and research use only devices. The future plan was however to develop software for
In Vitro Diagnostic Devices (IVD) which are more regulated, and more requirements
needs to be fulfilled in order to sell the devices in US and EU marketing areas. The
main problem to be researched in the thesis was to investigate what process
changes needs to be done to make the current software development process to be
compliant for software developed for IVD devices. In addition to this the goal of the
thesis was also to list what kind of documentation needs to be produced so that the
documentation complies with all the IVD documentation requirements. The scope of
the thesis was delimited to software development process related to lowest risk
category IVD devices, research use only devices and general-purpose laboratory
devices. Software validation and usability studies were also left out of scope but can
be analysed and introduced to the process in later stages.

The methods used in the thesis was selected to be action research. The action
research method allowed to analyse the background and source material in the
planning stage, execute a current state analysis for the gathered material in the
acting stage and finalize the process prototype in stakeholder workshops in
developing stage. Finally, the final process prototype was built to the application
lifecycle management (ALM) system and shared with the stakeholder and wider
product development group in the reflecting stage.

The results of the thesis show that similarly structured process can be used to
develop software for non-regulated and regulated software products. New process
structures need to be put in place and also new documentation generated by that
process needs to be implemented and preferably have document templates in place
to easily fulfil the requirements. Using regulated process structure, documentation
templates and hierarchy for non-regulated software also ensures that good common
practices are used in both environments and are then cohesive between projects.

Keywords: EU, FDA, IVD, IVDR, GPLE, RUO, Medical Device,

Software Development, Application Lifecycle Management,
Quality Management Systems
Contents

List of Abbreviations

1 Introduction 1

2 Action Research Method 4

2.1 Planning Stage 6

2.2 Acting Stage 7

2.3 Developing Stage 9

2.4 Reflecting Stage 11

3 Background 13

3.1 Legislative Authorities 13

3.1.1 EU Legislation 13

3.1.2 FDA Regulations 15

3.2 Scope of IVD 16

3.2.1 IVD Medical Device 17

3.2.2 IVD Medical Device Software 18

3.2.3 Harmonized and Recognized Standards 20

3.2.4 Quality Management Systems 21

3.2.5 Software Development Process 23

4 Current State Analysis 33

5 Development Process and Results 35

5.1 Data Collecting and Analysing Results 35

5.2 Process Prototyping 38

5.2.1 Minimum Viable Process 39

 5.2.2 Workshop Structure 41

5.2.3 Workshop Sessions 41

5.3 Final Process Prototype 43

5.4 Sharing and Communicating the Results 48

6 Discussions and Conclusions 50

References 54

Appendices
Appendix 1: Requirement Gap Analysis
Appendix 2: Process Requirements Based on Software Environment, SSC, and
LOC
Appendix 3: Workshop Meeting Minutes
List of Abbreviations

ALM Application Lifecycle Management. Comprises of specification,

design, development, and testing of software application in
software development processes.

CDRH The Food and Drug Administration’s Center for Devices and
Radiological Health. Regulates companies manufacturing,
repackaging, relabelling, and importing medical devices sold in the
United States.

CE Conformité Européenne. Marking of goods sold in the European

Economic area. Using the marking the manufacturer or importer
assures that the good conforms to European health, safety, and
environmental standards.

CFR Code of Federal Regulations. Codification of regulations declared

by the departments and agencies of the federal government of
United States of America.

CGMP Current Good Manufacturing Practice. Quality assurance area for

medicinal products which ensures that products are controlled and
produced according to the quality standards appropriate for their
intended use.

DHF Design History File. Compilation of documents which includes all

the design history of completed medical device.

EU European Union. International organization which includes 27

European countries and governs their common economic, social
and security policies.
FDA The Food and Drug Administration. US Agency responsible for
protecting public health by ensuring the safety, efficacy, and
security of human and veterinary drugs, biological products, and
medical devices.

GPLE General Purpose Laboratory Equipment. FDA’s definition of

laboratory devices intended to be used for preparation or
examination of specimens from the human body. These devices
are labelled or promoted for a specific medical use in the United
States marketing area.

HHS United States Department of Health and Human Services. US

department which goal is to improve health and well-being of US
citizens. It provides health and human services by advancing
science in the areas of medicine, public health, and social services.

ISO International Organization for Standardization. Worldwide

federation of national standards bodies and a nongovernmental
organization which comprises standards bodies from more than
160 countries, with one standards body representing each member
country.

IEC International Electrotechnical Commission. Organization which

produces and publishes international standards for electrical and
electronic systems and related technologies.

IVD In Vitro Diagnostics. Test which are developed to detect disease,

conditions, and infections from biological samples.

IVDD In Vitro Diagnostic Directive. Medical device regulatory framework

to ensure safety and performance requirements for in vitro
diagnostic medical devices in the EU market. Superseded by IVDR
in 2017.
IVDR In Vitro Diagnostic Medical Device Regulation. Medical device
regulatory framework to ensure safety and performance
requirements for in vitro diagnostic medical devices in the EU
market.

LOC Level of Concern. An estimate of the severity of injury used by FDA

that a device could permit or inflict, either directly or indirectly, on a
patient or operator because of device failures, design flaws, or
simply by virtue of employing the device for its intended use.

MDD Medical Devices Directive. Medical device regulatory framework to

ensure safety and performance requirements for medical devices in
the EU market. Superseded by MDR in 2017.

MDR Medical Devices Regulation. Medical device regulatory framework

to ensure safety and performance requirements for medical devices
in the EU market.

MVP Minimum Viable Process. Process version which includes

predefined process phases to be implemented in order it to be
completed and usable for future development.

QMS Quality Management System. Documented array of processes

functions and policies to ensure continuous improvement of quality.
System to ensure that customer requirements are met or exceeded.

QSR 21 Code of Federal Regulations 820. Part of the Current Good

Manufacturing Practice (CGMP) regulations. Ensures that medical
devices developed and sold in United States market are safe to use
and that they follow minimum quality processes during the
development stages.
RUO Research Use Only. FDA’s definition for devices which are
intended to be used in research use only and do not have medical
purpose or objective.

R&D Software research and development.

SOP Standard Operating Procedure. Collection of written instructions

including step-by-step guidance which has to be followed in order
to repeatability execute process in identical way.

SOUP Software of Unknown Provenance. Unknown software item which

has been developed with unknown software development process
or software development methodologies. Might have unknown
safety related properties.

SSC Software Safety Classification. An estimate of the severity of injury

used by EU that software could permit or inflict, either directly or
indirectly, on a patient or operator because of device failures,
design flaws, or simply by virtue of employing the device for its
intended use.

US United States of America.

 1

1 Introduction

Medical devices are regulated multiple ways in multiple areas all over the world.
In the context of this thesis the specific device types in focus are in vitro
diagnostics (IVD) devices, general purpose laboratory equipment (GPLE) and
research use only (RUO) devices.

IVD devices are mainly used in different types of testing of biological samples.
These samples may for example include tissue samples, blood samples or
urine samples to obtain information about person’s health. Examples of
common IVD tests are self-test for pregnancy and blood glucose monitors which
are commonly known test for public use. More sophisticated tests or diagnoses
performed in a regulated clinical laboratory environment such as HIV (Human
Immunodeficiency Virus) tests, identification of blood types and cancer
screening. What differentiates IVD devices from medical devices and
pharmaceuticals is that IVD devices do not come into contact directly with a
person, do not treat patients or do not cause direct harm to a patient. IVD thus
are for providing information about how the patient’s body is functioning. The
main risks concerning IVD products are that their usage cause incorrect
diagnosis. Due to the risk posed by IVD devices, different regulations, norms,
and standards apply for these types of devices. In most countries they are
required to be registered. [1]

GPLE refers to equipment which can be used in wide range of laboratory

applications, and they are not usually specialized to specific tasks. GPLE
devices are not considered as IVD devices unless they are promoted and
labelled to be used for preparation or examination of IVD specimens. Examples
of these devices include microscopes, pipettes and purification instruments. [2]

If device is labelled as RUO, the intended use is for research in general

laboratories. These environments include basic laboratory research,
performance investigation in research environments and investigation of design
of the devices. Similar standards and norms do not apply for RUO devices so
 2

these products can be more or less regulated depending on the country

developed and used in. RUO products thus do not belong under IVD regulations
since they do not have any clinical application and they are not categorized as
medical device by law. The main RUO products are reagents, instruments or
systems including reagents and instrument which are under development and
evaluation to be used as potential IVD instrument. RUO devices are not
regulated but they need to be labelled for research use only. The second target
environment for RUO devices is for nonclinical laboratory research. These
environments are mainly used to do basic life science research. The main
difference for these use cases is that the devices are used to conduct research
and not to be object of research themselves. [1]

Developing software and firmware for in IVD devices is more strictly regulated
than developing software for RUO or GPLE devices. Additional standards and
requirements for software development processes needs to be considered
when moving from GPLE or RUO device development processes to IVD
regulated application lifecycle management (ALM) processes.

The customer of the thesis work is established medical device developer and
supplier in producing instruments, instrument consumables and device related
software. The company provides GPLE, IVD and RUO devices in multiple
regulated fields, but processes may vary between different geographical areas.

Currently the company’s software development process is used to develop

GPLE devices since the main intended uses are on research and development
use. The problem is that the customer is starting to develop IVD devices, and
the current research use only development environment does not conform to
the legislative requirements of the European Union (EU) In vitro diagnostic
medical device regulation (IVDR) and United States Food and Drug
Administration (FDA) IVD regulation.

The thesis focuses on software development process and tool used in the
application lifecycle management. The processes, documentation produced by
 3

the processes and tools needs to be evaluated to get a picture of what needs to
be done to make those parts of software development process conform the
current IVD regulations. Since the customer is focusing on IVD related software
development, it is particularly important that the software development process
is designed to fulfil the requirements.

The company has all the required Standard Operating Procedures (SOP), work
instructions and document templates for the Design History File (DHF)
available. These documents are the basis on designing and implementing a
process structure which is then used in software development to fulfil the
process requirements and documentation requirements emerging from this
study. These available documents will be used to conduct a gap analysis
between the current processes documentation which is used to develop GPLE
devices containing software and the new processes and documentation
developed for the RUO and IVD devices containing software. From this gap
analysis a process prototype is developed to be analysed by stakeholders in
workshops. Stakeholders participating the overall development of the process
are individuals working in the software development department and involved in
the practical use of the software development in general. This group includes
R&D Software engineering manager for PC software, R&D Software
engineering manager for embedded software, Software architect, Software
product owner and R&D Manager of Product Lifecycle Management. The
analysis is executed in iterations where the process is evaluated, feedback is
analysed, and process is developed based on the feedback and analysis. Final
product of the thesis work is a final process prototype to be taken into
production use in the company’s software development team’s ALM system
where it will be used to develop the next IVD device software system.
 4

2 Action Research Method

This section explains the chosen research methods for the thesis, reasoning
behind the selected research method and explanation on how the research
method is used in the thesis

The main premise of the thesis is software development process. These types
of processes are very constructed processes and based heavily on predefined
regulations and requirements. The thesis research subject is a real-world
problem which needs to be solved and the target is to develop high-level
software development process prototype to be used in IVD software
development as a platform for future projects.

Based on these there needs to be a plan for the new process design and
implementation. The thesis subject also relies heavily on researching the
subject matter, the current implementation and requirement level research
produced by the legislation. This research should also include collaboration with
the team members involved in the software development process to get to know
the practical implications of the process itself. There also needs to be a process
prototyping phase where the new process template is evaluated with
stakeholders and final prototype which is then evaluated in the production use.

Looking at the overall background and research structure, the action research
method was a good fit to be used to conduct this research. The thesis subject
focuses on software development process which is very constructed process by
default and the overall subject depends on real world execution and prototyping.

The main idea of action research is acting on research. This means that the
theory behind the research is connected to a practical solution which is then
executed to improve the problem behind the identified theory. It is an iterative
model which contains certain phases. These phases include a planning stage,
acting stage, developing stage and reflecting stage. Figure 1 shows how each
 5

phase is connected and what is included in each phase in the concept of action
research model visualized after [3].

Figure 1. Action research concept [3 pp. 37].

Action research is not very strictly defined method and can be tailored to meet
the needs of each different research topics in different areas. To facilitate action
research in this thesis, the overall workflow differs from the original concept
idea.

Based on each step of the action research process in theory, the overall
research approach for the thesis was created. Figure 2 shows the overall
process which will be used to conduct the research and how each phase is
linked to the action research stages:
 6

Figure 2. Action research process customized for the thesis.

Each of the stages and how they are managed in the customized process are
explained in detail in the following subchapters.

2.1 Planning Stage

The first phase of the action research is the planning stage. The first step of the
planning stage is to identify and limit the researched topic. In this thesis the
identification of the topic and limiting the scope of the research is presented in
the Introduction section where the overall premise of the thesis is introduced,
and the focus of the thesis is explained. [3 pp. 36]

The second step is to develop a research plan based on the identification and
limiting the research subject. This plan includes a data collection plan for the
current state analysis, background information and data analysis plan used in
the thesis [3 pp. 36]. This is also included in the Introduction section together
with the first step of the planning stage.
 7

Third step of the process is to gather all the information necessary to conduct
the research. In this thesis this includes the current state analysis of the
software development processes and the new requirements affecting these
processes provided by the customers SOPs and process templates. This step is
included in the section Current State Analysis.

Fourth step of the planning process is to review the related literature connected
to the topic of the research [3 pp. 36]. This includes the technical background of
the IVD requirements and the reasoning why this thesis is made and what are
the current requirements affecting the processes described in the thesis
research.

These chapters include all the necessary planning and background information
needed to start the whole action research process and are embedded to the
overall structure of the thesis.

2.2 Acting Stage

Acting stage includes data collection, gap analysis including current state
analysis results and overall data analysis where all the gathered information is
collected.

The first step of the acting stage is to collect all the necessary data gathered in
the current state analysis and background information research [3 pp. 36]. After
data is researched and gathered from both the customer processes and IVD
related source material, it is assumed that the preconstructed structure of data
used when gathering information is similar. Then it is easier to do analysis and
especially gap analysis between the current implementation and what is needed
to be implemented. It helps to find the similarities and differences between the
source materials. Interview structure in the development stage should also be
based on similar structure.
 8

Practical data collection methods will be divided into three main phases. The
first step is to start investigating the current application lifecycle management
system and software development process to find out what the customer
currently has and what is missing based on the first part. The second phase is
to study and research the IVD documentation which includes the processes,
work instructions and document templates and how these fit to the customers
current implementation.

The second step is to analyse the collected data. Data analysis method used in
this thesis will be mostly qualitative. When researching the source material,
observations will be made on the source material and data is then analysed
based on predetermined structure using inductive process. This means that the
research examines the source material and data for common patterns and
similarities and based on this analysis a general theory is formed from the
source material [3 pp. 43]. Traditionally during qualitative research processes,
data analysis is conducted in parallel with data collection phases and is finalized
when data collection is finished. Action research however the data analysis
continues throughout the research process [3 pp. 36].

Third step of the acting phase is to execute a gap analysis for the collected and
pre-analysed data. A gap analysis means a method to measure current results
to the expected results. It tries to find missing or insufficient information,
strategies or processes between the current state and expected state. This
method then gives results for recommended actions which can be conducted to
achieve the expected state. [4]

Purpose of the gap analysis in the thesis is to compare each of the stages and
structure gathered and to create gap analysis matrix to be further analysed. In
the analysis, following key points are identified:

• Reusable material and documentation.

• Legislation and standards referenced in both processes.

• Software development process phases used in both processes.

 9

• Documentation produced in both processes.

• Missing material and documentation required in the new IVD

development process.

• New legislation and standards needed to be referenced in the

process.

• New software development process phases to be included in the new

IVD development process.

• New documentation needed to be created during the new IVD

development process.

• Material used in the current process but not needed in the new IVD
development environment.

• Legislation and standard references which are obsolete or

unnecessary for the new IVD development process.

• Software development process phases which are not required by the

new IVD development process.

• Documentation produced which is not required by the new IVD

development process.

Based on the previous gap analysis and identified changes all results are
gathered to a single gap analysis matrix. All changes differences and change
request must be reasoned within the matrix based on the new IVD
requirements. From this structural document the first prototype can be
structured to be reviewed.

2.3 Developing Stage

In the action research process, developing stage focuses on developing an

action plan after the data is collected and analysed in the previous phase [3 pp.
36]. Developing stage includes the process implementation or in this case
process prototyping phase. Prototype means the overall structure of the
 10

expected process in high level and design of the structure to be later

implemented into to the ALM. The prototype model is tree-structure which
consists of main product and then branches to subprocesses, and
documentation related to each phase. This structure template can be then used
in the research process. The initial prototype structure can be seen in Figure 3:

Figure 3. Software development process initial prototype structure.

This stage also includes stakeholder workshops where the prototype design is
evaluated, and feedback is gathered to be implemented in the current process
prototype. The differences in the iterative process are most evident in this stage
of the process. The main iterative cycle is focused on the development phase
between the stakeholder workshops and process prototyping. The data
managed in the planning and acting stages cannot be influenced by the
development phase in the concept of the thesis. Therefore, the iterations are
restricted to the development phase only. Going back to previous phases is not
 11

restricted during the action research process, but it is not defined as a regular
iterative cycle.

When this combined data retrieval phase is done, the interview material is
analysed, and feedback is gathered from stakeholders. After this all the
gathered information is combined and analysed; things that are already
implemented correctly to the current process, things that need to be integrated
to the current process, user needs for the new process and documentation of
the current process. This evaluation is done by prototyping and gathering
feedback from the stakeholders in an iterative process. This iterative
development includes conducting interviews and discussions with stakeholders
about their expectations on best practices to integrate these processes. This
also includes prototyping of the new high-level structure and process.

The last step of the development phase is to gather all the feedback and
changes from the previous step and create final prototype. This includes
creating a high-level process description and prototype to single document. The
document can be then presented and shared in the reflecting phase for
stakeholders and also for related groups outside the software development.

2.4 Reflecting Stage

Action research reflecting stage includes sharing and communicating the

research results and reflecting the overall action research process used [3 pp.
36]. In the thesis the reflecting stage consists of sharing and communicating the
final process prototype of the action research project outside the development
and stakeholder team. This phase is also excluded from primary iterative cycle.
Results and communication are primarily moving between the development and
stakeholder groups in the development phase, but when the MVP (Minimum
Viable Process) is achieved, the results are communicated to the stakeholders
but also to the software management and project management related to the
software processes to present the overall research and results.
 12

This stage also includes retrospective analysis on how the theoretical research
connects to the current designed process and documentation changes in the
new solution to evaluate the impact of the changes to the process and if
planned goals were achieved. If there are any pending items or change request
rising from the reflecting stage or the environments have been changed after
the final process has been finalized, the action process can be started from the
planning stage and the action research process can be executed as another
iterative round.
 13

3 Background

This section explains the legislative background information for the thesis. The
focus is on the European Union (EU) and United States (US) market areas. This
section also explains what the regulatory organisations in each market area are
and what are the main legislative acts which need to be considered when
developing IVD software. The last two sub-chapters overview the harmonized
standards for these acts and how they related to software development
processes.

3.1 Legislative Authorities

In the context of this thesis, two major regulative authorities and marketing
areas are being studied. The EU and US markets are the two major market
areas which the customer is focusing on so the path to market in these areas
are the most important ones. There are also other target areas but fulfilling the
requirements in these areas also fulfil the requirements in other secondary
market areas as they are or with minor adjustments. The next two chapters
explain the overall legislations and regulations related to these two main target
areas.

3.1.1 EU Legislation

EU is the highest organization in Europe which regulates medical devices

manufacturing. EU enforces legislation in two levels which are primary and
secondary. EU treaties or primary legislation is the backbone of all the actions
made by the EU. The secondary level of EU legislation consists of different type
of legal acts which also include directives and regulations. These legal acts are
more detailed instructions for the member countries to fulfil the primary
legislation requirements. [5 pp.17]
 14

The main legislative component related to products in EU are directives and

regulations. Directives are legislative acts which consists of rules which all
member countries must adopt and adjust to their own national legislation. These
directives also have a deadline which states when the member states must
have the directive included in the national legislation [5 pp. 17]. Regulations are
legislative acts which all member states must apply to the internal legislative
structure immediately after the regulation has been published.

The main legislative acts concerning medical devices are MDR (Medical Device
Regulation) EU 2017/745 and In Vitro Diagnostic Medical Device regulation
2017/746. Both, as all, regulations need to be applied as they are in all the
member states of the EU. The IVDR defines the purpose of the regulation:

“This Regulation aims to ensure the smooth functioning of the

internal market as regards in vitro diagnostic medical devices,
taking as a base a high level of protection of health for patients and
users, and taking into account the small and medium-sized
enterprises that are active in this sector. At the same time, this
Regulation sets high standards of quality and safety for in vitro
diagnostic medical devices in order to meet common safety
concerns as regards such products. Both objectives are being
pursued simultaneously and are inseparably linked whilst one not
being secondary to the other. As regards Article 114 of the Treaty
on the Functioning of the European Union (TFEU), this Regulation
harmonises the rules for the placing on the market and putting into
service of in vitro diagnostic medical devices and their accessories
on the Union market thus allowing them to benefit from the principle
of free movement of goods. As regards Article 168(4)(c) TFEU, this
Regulation sets high standards of quality and safety for in vitro
diagnostic medical devices by ensuring, among other things, that
data generated in performance studies are reliable and robust and
that the safety of subjects participating in performance studies is
protected.” [6 pp. 1]
 15

The main objective is to define main regulative requirements for safety, quality,
and performance of IVD devices. This ensures that the devices in use in EU
area are safe and not a health risk to patients or users. Following the regulation
also guarantees that the device performance and reliability is in the level as
manufacturers state. [6 pp. 1]

The IVDR describes the methods that all the IVD medical device manufacturers
must follow to sell the devices in EU area. Device manufacturer must specify in
which risk category specified by the regulation the device belongs to. This can
be achieved by conducting formal risk analysis for the device and its intended
use. In addition to the risk analysis, manufacturer shall meet the general safety
and performance requirements specified in Annex I of the IVDR. The IVDR also
specifies a conformity assessment procedure for all devices which can be
conducted by the manufacturer. In particular cases for higher risk class devices,
a notified body must conduct the conformity assessment. In most cases
however the risk category is so low that manufacturer may conduct the
conformity assessment without involving a notified body. [5 pp. 27]

Fulfilling all the requirements set in the IVDR the manufacturer can obtain CE
(Conformité Européenne) marking for the device which is manufacturers
guarantee that the device has been developed according to EU regulations and
can be sold in the EU area as IVD device.

3.1.2 FDA Regulations

FDA is the highest organization in US who controls and regulates the

manufacturing of medical devices targeting US markets. FDA is an agency
which operates under US Department of Health and Human Services (HHS).
FDA is the oldest government agency which is focused on consumer protection
and to protect and promote product aspects related to health. In addition to
medical devices, FDA regulations also cover food, drugs, cosmetics, biologics,
veterinary and animal medicine and tobacco related products. [7]
 16

The main FDA branch which regulates medical devices and radio emitting
products is the CDRH (Center for Devices and Radiological Health). CDRH has
the role of evaluation safety and effectiveness of medical devices during
manufacturing processes and after the device reaches the market. [8]

There are also requirements to consider for the manufacturers to get IVD
devices to the US market. Device manufacturer must register the manufacturing
establishment to FDA database providing information about the manufacturing
facilities and import methods. The manufacturer is also responsible to register
their IVD product to medical device listing for FDA. This does not automatically
give the manufacturer permission to produce and distribute the device for US
market. To get permission, device manufacturer must define an intended use
for the product and do a risk analysis for the product related to its intended use.
Device manufacturer must also follow a quality system regulation requirement
intended for the specified IVD product, classify the device based on its intended
use and register its country of origin. The main regulation which manufacturers
must follow is 21 CFR (Code of Federal Regulations) 820. After these
processes, registrations and approvals, manufacturer can produce IVD products
for US markets. After the IVD device has been released to market, FDA
regulates the manufacturing, distribution, and customer feedback by conducting
audit to the manufacturing facilities and organization. [9]

3.2 Scope of IVD

This section focuses on defining and delimiting the scope of the evaluated IVD
requirements and what is the definition of IVD medical device and how software
is treated in the regulated environment. There is other legislation in the global
and local aspect affecting IVD products but in the context of the thesis, the
focus is on the IVD devices and especially software classified as IVD device or
as part of an IVD device.
 17

3.2.1 IVD Medical Device

IVD devices are medical devices which have specific intended use and fall
under the legislative requirements of medical devices and MDR. IVD devices
have more specific areas of use and both the EU and FDA have their own
definition of IVD medical device. The IVDR specifies IVD medical device as
follows:

“‘in vitro diagnostic medical device’ means any medical device

which is a reagent, reagent product, calibrator, control material, kit,
instrument, apparatus, piece of equipment, software or system,
whether used alone or in combination, intended by the
manufacturer to be used in vitro for the examination of specimens,
including blood and tissue donations, derived from the human body,
solely or principally for the purpose of providing information on one
or more of the following:

(a) concerning a physiological or pathological process or state;

(b) concerning congenital physical or mental impairments;

(c) concerning the predisposition to a medical condition or a

disease;

(d) to determine the safety and compatibility with potential

recipients;

(e) to predict treatment response or reactions;

(f) to define or monitoring therapeutic measures. Specimen

receptacles shall also be deemed to be in vitro diagnostic medical
devices;”. [6 pp. 13]
 18

FDA has its own definition for IVD devices the regulation The 21 CFR Part 809:
“In vitro diagnostic products for human use” specifies it as follows:

“(a) In vitro diagnostic products are those reagents, instruments,

and systems intended for use in the diagnosis of disease or other
conditions, including a determination of the state of health, in order
to cure, mitigate, treat, or prevent disease or its sequelae. Such
products are intended for use in the collection, preparation, and
examination of specimens taken from the human body. These
products are devices as defined in section 201(h) of the Federal
Food, Drug, and Cosmetic Act (the act), and may also be biological
products subject to section 351 of the Public Health Service Act.”
[10]

Both definitions have similar specifications for IVD devices, but the IVDR
definition is more detailed. In more simple terms the IVD devices are tests for
biological samples from human body to determine persons health. This includes
detecting and preventing diseases and other conditions, curing, and treating
diseases, and monitoring overall health. Examples of these IVD devises are
pregnancy tests, blood glucose tests, HIV and COVID-19 tests. [11]

Invasive products which are in direct contact with human body to obtain
specimens are not regulated by IVDR but MDR. IVD regulated test and devices
are always conducted outside the human without contacting or invading the
body tissue. [5 pp. 51]

3.2.2 IVD Medical Device Software

Software can be qualified as IVD medical device if the medical device has
medical implications based on its intended use. When the manufacturer
describes the IVD medical device intended use, the software related to the
medical device or if the software itself is a medical device must have effect on
the classification or qualification of the medical device.
 19

The IVDR further clarifies the software classification in context of IVD medical
devices:

“(17) It is necessary to clarify that software in its own right, when

specifically intended by the manufacturer to be used for one or
more of the medical purposes set out in the definition of an in vitro
diagnostic medical device, qualifies as an in vitro diagnostic
medical device, while software for general purposes, even when
used in a healthcare setting, or software intended for well-being
purposes is not an in vitro diagnostic medical device. "The
qualification of software, either as a device or an accessory, is
independent of the software's location or the type of interconnection
between the software and a device.”" (“Digital Health - The New
Regulation of Medical Software and Apps”)” [6 pp. 178]

To be qualified as an IVD medical device software under IVDR, the intended

use and the software itself must fulfil the previous requirement.

The FDA regulations are not defining the IVD medical device software and
especially in so detail as the IVDR. The 21 CFR Part 809: “In vitro diagnostic
products for human use” does not differ IVD medical device software from the
IVD medical device definition. When compared to the IVD device definition it is
similar to the IVDR definition of medical device. The “General Principles of
Software Validation; Final Guidance for Industry and FDA Staff” which is an
FDA guidance for medical device manufacturer lists software related
specifications for which the guidance applies:

“Software used as a component, part, or accessory of a medical

device;

• Software that is itself a medical device (e.g., blood establishment

software);" (“General Principles of Software Validation; Final
Guidance for Industry ...”)
 20

• Software used in the production of a device (e.g., programmable

logic controllers in manufacturing equipment); and" (“General
Principles of Software Validation; Final Guidance for Industry ...”)

• Software used in implementation of the device manufacturer's

quality system (e.g., software that records and maintains the device
history record).” [12 pp. 2]

The FDA interpretation would also support the fact that if the software impacts
the device classification and qualification of the IVD medical device itself or as a
part of an IVD system, the software needs to be managed as regulated software
within EU and US marketing areas. [13 pp. 7]

3.2.3 Harmonized and Recognized Standards

To fulfil the requirements set by the regulations and requirements set by these
regulations, the manufacturer may use internationally recognized standards.
FDA designation for these standards is recognized consensus standard and EU
describes them as harmonized standards. Globally recognized standards can
be used to conform with the safety and performance requirements required by
the FDA IVD regulations and IVDR. These standards are made possible by
global working groups which include International Organisation for
Standardization (ISO) and the International Electrotechnical Commission (IEC).

These standards are created so the manufacturers have unified framework to

develop IVD products and mutual understanding and structure of the required
methods and documentation described in the standards. It is also good practice
to utilize these standards where such standard exists, since manufacturers then
do not have to develop their own means to meet the IVD requirements. In both
the EU and US marketing areas, the harmonized standards are for most parts
the same. Both the FDA and EU maintain a list of standards which can be used
to fulfil the regulations and directive requirements and areas in which they can
be applied. [5 pp. 33]
 21

3.2.4 Quality Management Systems

The most important requirement from both FDA and EU is that the manufacturer
must have Quality Management System (QMS) in place when manufacturing
and distributing IVD medical device. The purpose of these quality management
systems is to ensure that the products and services are provided with high
quality standards throughout the manufacturing organization. These quality
management systems describe processes and procedures which allow
manufacturers to demonstrate that they can manufacture IVD medical device
and services related to those products and that these meet the regulatory and
customer requirements defined to the products. The stages of device lifecycle
specified by the different quality management systems may include device
design and development processes, production processes, storage processes,
distribution processes, installation and servicing of the device and technical
support for the device. This also applies to suppliers and external services
which are used during the device life cycle. [5 pp. 100]

Since the manufacturer is required to maintain a Quality Management System

the most common option is to follow ISO 13485:2016 “Medical devices. Quality
management systems. Requirements for regulatory purposes.” The standard is
based in ISO 9001 quality management system standard. The ISO 9001 is an
international standard for quality management system which can be utilized to
any organization and does not specify any industry, product, or service. The
standard can be only used for general purpose laboratory devices and is not
applicable to IVD devices as is. The ISO 13485 was developed to focus on
medical devices and medical device environments and has more detailed
requirements concerning the medical device industry [5 pp. 101]. This standard
is also included in the harmonized standards list for IVDR and can be used to
fulfil the quality management system requirements stated by the IVDR. [14]

FDA uses its own quality management systems specifications which is a part of
Current good manufacturing practice (CGMP) requirements set by the
regulation 21 CFR Part 820 (QSR). This system allows manufacturers in US
 22

market area to fulfil the same requirements as the ISO 13485 for IVD devices.
FDA has not yet approved the ISO 13485 to be recognized consensus
standard, but the FDA has issued a proposed rule on 23 rd of February 2022 to
align the quality management system regulations and include the ISO 13485 as
recognized consensus standard. [15]

Even though the US and EU market areas require different quality management
systems, the general structure and requirements can be traced between both
systems. Correlations between the two can be seen in Table 1.

Table 1. Correlation between QSR requirements with ISO 13485:2016

requirements.

ISO 13485:2016
Regulatory section QSR [16]
[17]

Design and Development Planning 820.30(b) 7.3.2

Design Input 820.30(c) 7.3.3

Design Output 820.30(d) 7.3.4

Design Review 820.30(e) 7.3.5

Design Verification 820.30(f) 7.3.6

Design Validation 820.30(g) 7.3.7

Design Transfer 820.30(h) 7.3.8

Design Changes 820.30(i) 7.3.9

Design History File 820.30(j) 7.3.10

Risk Management 820.30(g) 7.1

Based on this comparison and evaluation, the ISO 13485:2016 can be used
fulfil the requirements to a degree but using the standard does not automatically
 23

fulfil the FDA regulation. QSR must be integrated to the manufacturers quality
management system to get the FDA approval.

3.2.5 Software Development Process

The development process is only a part of each quality management systems.

In the context of this thesis, the main focus is on product development process
and in more detail software development process.

The most used current standard concerning software development and

maintenance for IVD medical devices is IEC 62304:2006, Medical device
software lifecycle processes. This standard is not yet harmonized for the IVDR,
but it was harmonized for the superseded Directive 98/79/EC [18] and
recognized as consensus standard by the FDA [19]. Taking these into account
the IEC 62304:2006 is the most straightforward way to make sure that the
software development lifecycle covers all the requirements stated in the IVDR
and QSR.

The detail level of the whole software development process is dependent on the
Software Safety Class (SSC) which are defined in the IEC 62304. There are
three different SSCs: A, B and C. This safety class definition only applies to the
IEC 62304 standard and should not be mixed with medical device safety class
[5 pp. 68]. SSCs are specified in the IEC 62304 as follows:

“Class A: No injury or damage to health is possible

Class B: Non-SERIOUS INJURY is possible

Class C: Death or SERIOUS INJURY is possible” [20 pp. 29]

Similarly, in QSR the estimated severity device inflicted injury is divided into
levels which are called Level of Concern (LOC). These levels are specified in
the Guidance for the Content of Premarket Submissions for Software Contained
in Medical Devices document. The levels describe the severity of injury caused
 24

directly or indirectly to the patient or operator by device failures, design flaws or

just by using the device for its intended use [21 pp. 4-5]. LOCs are specified as
follows:

“Major

We believe the level of concern is Major if a failure or latent flaw

could directly result in death or serious injury to the patient or
operator. The level of concern is also Major if a failure or latent flaw
could indirectly result in death or serious injury of the patient or
operator through incorrect or delayed information or through the
action of a care provider.

Moderate

We believe the level of concern is Moderate if a failure or latent

design flaw could directly result in minor injury to the patient or
operator. The level of concern is also Moderate if a failure or latent
flaw could indirectly result in minor injury to the patient or operator
through incorrect or delayed information or through the action of a
care provider.

Minor

We believe the level of concern is Minor if failures or latent design

flaws are unlikely to cause any injury to the patient or operator.” [21
pp. 5]

Table 2 is a combined overview of what areas are covered by the IEC

62304:2006 safety class and QSR level of concern.
 25

Table 2. Mandatory requirements for software IVD products based on their

safety class and level of concern.

Safety Level of
Number Section Description
Class Concern

General Required
Required
General requirements for for Level
4 for safety
Requirements the software of Concern
class [20]
manufacturer. [21]

Requires
manufacturer to
Quality Minor,
use and document
4.1 Management A, B, C Moderate,
the used quality
System Major
management
system.

Requires
manufacturer to
Minor,
comply with ISO
4.2 Risk Management A, B, C Moderate,
14971 risk
Major
management
process.

Requires
manufacturer to Minor,
Software Safety
4.3 assign safety class A, B, C Moderate,
Classification
for the regulated Major
software.

Requirements for
Software Minor,
the software
5 Development A, B, C Moderate,
development
Process Major
process.
 26

Safety Level of
Number Section Description
Class Concern

Requirements for
Software Minor,
the software
5.1 Development A, B, C Moderate,
development
Planning Major
planning

Requirements on
how to define and
Software Minor,
document software
5.2 Requirements A, B, C Moderate,
requirements from
Analysis Major
the system level
requirements.

Requirements on
how to define and
Software
document software Moderate,
5.3 Architectural B, C
architecture from Major
Design
the software
requirements.

Requirements for
Software Detailed software unit and
5.4 B, C N/A
Design interface design
description.

Software Unit Requirements for Minor,

5.5 Implementation software unit A, B, C Moderate,
and Verification implementations. Major

Software Requirements for

Integration and software integration
5.6 B, C N/A
Integration and integration
Testing testing.
 27

Safety Level of
Number Section Description
Class Concern

Requirements for
software system Minor,
Software System
5.7 testing when testing A, B, C Moderate,
Testing
system Major
requirements.

Requirements for
defining system
verification
completion and
5.8 Software Release A, B, C N/A
documentation
requirements for
the released
software.

Requirements for
Software
software Moderate,
6 Maintenance A, B, C
maintenance Major
Process
process

Establish Requirements for

Moderate,
6.1 Software software A, B, C
Major
Maintenance Plan maintenance plan

Requirements for
Problem and feedback, problem
Moderate,
6.2 Modification resolution process A, B, C
Major
Analysis and evaluation
analysis.

Modification Requirements for Moderate,

6.3 A, B, C
Implementation modification Major
 28

Safety Level of
Number Section Description
Class Concern

planning and
implementation for
the software

Software Risk Minor,

(Referenced ISO
7 Management - Moderate,
14971)
Process Major

Requirements for
analysing software
Analysis of
contributing to
Software Minor,
hazardous
7.1 Contributing to B, C Moderate,
situations, potential
Hazardous Major
causes, sequence
Situations
of events and
documentation.

Requirements for
planning and
Minor,
Risk Control documenting risk
7.2 B, C Moderate,
Measures control measures
Major
for each identified
risk.

Requirements for
planning and
Verification of documenting Minor,
7.3 Risk Control verification B, C Moderate,
measures activities for each Major
risk control
measure.
 29

Safety Level of
Number Section Description
Class Concern

Requirements for
Risk Management risk analysis and Minor,
7.4 of Software management for A, B, C Moderate,
Changes changes affecting Major
safety.

Requirements for
software
Software
configuration
Configuration Moderate,
8 management A, B, C
Management Major
process including
Process
configuration items
and SOUP.

Requirements for
Configuration identifying each Moderate,
8.1 A, B, C
Identification item in the software Major
configuration.

Requirements for
change control
process when
Moderate,
8.2 Change Control changes are A, B, C
Major
planned to be
implemented to the
configuration.

Requirement for
Configuration manufacturer to Moderate,
8.3 A, B, C
Status Accounting retain records Major
history of the
 30

Safety Level of
Number Section Description
Class Concern

controlled
configuration items.

Requirements for
Software Problem the software Minor,
9 Resolution problem resolution A, B, C Moderate,
Process process of the Major
software product.

When the safety class is defined, the IEC 62304 determines which
requirements are applicable for each class software. If the safety class is
determined to be class C after all risk management procedures, all
requirements apply to that software product. On the other hand, low risk class A
software is exempted from particular requirements which can be seen form
Table 2.

The standard describes requirements for all the phases of software

development process and maintaining the developed software. It also specifies
the level of documentation produced by these processes and includes
descriptions of verification activities required for the software products. This
standard does not include requirements for IVD device validation and final
release, but those are required by the IVDR, ISO 13485 and QSR.

When all the requirements combined from the ISO 13485, QSR and IEC 62304
Table 3 shows the connection between each section of the requirement.
 31

Table 3. Comparison between QSR, ISO 13485 and IEC 62304.

ISO IEC
Regulatory section QSR [15] 13485:2016 62304:2006
[17] [20]

Design and Development

820.30(b) 7.3.2 5.1
Planning

Design Input 820.30(c) 7.3.3 5.2

Design Output 820.30(d) 7.3.4 5.3, 5.4, 5.5

Design Review 820.30(e) 7.3.5 N/A

Design Verification 820.30(f) 7.3.6 5.5, 5.6

Design Validation 820.30(g) 7.3.7 5.7

Design Transfer 820.30(h) 7.3.8 5.8

Design Changes 820.30(i) 7.3.9 8

Design History File 820.30(j) 7.3.10 N/A

Risk Management 820.30(g) 7.1 4.2, 7

Software Safety
N/A N/A 4.3
Classification

Software Maintenance N/A N/A 6

Software Configuration
N/A N/A 8
management

Software Problem 820.30(i),

N/A 9
Resolution process 820.198

When these requirements are compared in Table 3, there are similarities in

structure and each section between the QSR, ISO 13485 and IEC 62304. In
 32

addition to the design requirements from the QSR and ISO 13485 the IEC
62304 defines additional software related requirements. Based on this,
combining these structures to a similar process can be quite straightforward on
a higher level. Combining more detailed information on each requirement would
require additional work.

Figure 4 shows the IEC 62034 software development process workflow. This
workflow shows all the related process phase where requirements are applied.

Figure 4. IEC 62304:2006 software development process workflow [20 pp. 13].
 33

4 Current State Analysis

This section explains the status of the customer’s software development process.
It also gives an overview of what kind of processes are currently used and what
documentation is available.

Currently the customer’s software development process is used to develop

general purpose laboratory products. The problem is that the customer is
starting to develop IVD devices, and this environment does not conform to the
legislative requirements of the IVDR and FDA IVD regulations.

The first phase of determining the current development process was to gather
all the information from customer databases. It is known that the software
development process is not designed to be valid in IVD regulated environments,
its main purpose is to develop software for general laboratory use. It started by
going through the software development process and referenced standards.

Two main documents identified in the customer’s systems are the main process
description documents for product development process and the software
development process:

• The “Product development process” -document describes the whole

product development process on high-level.

• “Software development process” -document describes the phases

involved in the software development lifecycle.

The overall approach of the “Product development process” document is to

describe the whole product life-cycle process regarding a specific product. This
document does not limit to software products but to all mechanical products as
well. The document is designed to fulfil quality management system
requirements of ISO 9001:2015 and ISO 13485:2016. This document does not
contain any software specific information but refers to the other “Software
development process” document.
 34

After this the focus moved to the software development process. When going
through the document, it was clear that the only reference was to the ISO
9001:2015 standard. This is clearly a custom software development process
and none of the current software development standards are referenced here.
This strengthens the assumption that there is no regulation related standards
used.

Conclusion on researching the current development process is that there are a

number of IVD development related requirements which the customer has not
considered when developing the software development processes. Especially
the lack of using IEC 62304 during the process development shows that most of
these requirements are missing from the overall process. These gaps will be
further analysed in the data analysis phase of the research process.

Customer already has FDA and IVDR product and software development
process documented. However, this documentation is not in use in the
department which is expected to start developing software for IVD products.
The new documentation does not follow the same processes or SOPs that the
target environment is currently executing.

Based on this evaluation it was discovered that there is already process

documentation, work instructions and document template for this kind of
software development environment. All these documents are created to follow
the current IVD and FDA regulations and requirements. These documents are
not developed for customers’ needs and do not describe the current process as
it is. It is however plausible to use this documentation as a basis for the
changes for the current software development process. Comparing the
documents to the current software development process using gap analysis will
supply detailed information about what needs to be implemented to the current
software development process required by the new IVD documentation.
 35

5 Development Process and Results

This section describes the practical research work based on the gathered
background data and current state analysis. The first phase includes data
collection and analysis which consist of gathering all the related data and
documentation for the gap analysis to be conducted and the first prototype to be
introduced to the stakeholders. The second phase is to execute the process
prototyping phase together with stakeholders to evaluate and get feedback for
the final process prototype. The prototyping phase will be executed in iterations
to get feedback for the prototypes as soon as possible. Third and fourth phase
represents the final process prototypes and review if the set targets were
achieved and if the process is ready to be put to production.

5.1 Data Collecting and Analysing Results

The focus of the data collection was to gather all the data from current state
documentation and organize the data in format which allows the best starting
point for gap analysis between the main two source material sets: current
software process and the new IVD process documentation. The data combines
all the sections from QSR, ISO 13485 and IEC 62034 requirements to a single
dataset in high level to show the overall structure to be basis of the gap
analysis.

When looking at the gap analysis the main finds are that all the IVD specific
requirements are missing from the current process. For example, defining the
LOC and SSC are missing from the current process. This was expected since
the current process did not take IVD requirements into account. Other
significant difference was that some of the IVD related processes are not
defined in the current process in software level. These processes include:

• Software Design Transfer and Release Process

• Software Maintenance Process

 36

• Risk Management Process

• Software Configuration Management Process

• Software Problem Resolution Process.

Rest of the gaps include single items, process parts and deliverables which are
not included in the current process.

The gap analysis consists of seven different datasets in each column. First
column defines the main standard or regulation related to the requirements, the
second column describes the section number of each requirement in the related
standard or regulation. The third column defines the requirements form QSR,
ISO 13485 and IEC 62034. Fourth column describes if the requirements is
included in the current software development process. Fifth column describes
all the deliverables needed to be produced to comply with each requirement.
Sixth column describes if the requirement is included in the new process.
Seventh column includes initial analysis on the gap analysis for each
requirement. The whole gap analysis sheet can be found from Appendix 1.

The gap analysis results identified that the integrated process model requires
several new process phases and additional documentation. After the initial gap
analysis, it was also recognized that the main structure of the processes is
almost identical, so it will make further integration and prototyping a lot easier.

Since the new IVD process includes all the necessary requirements to be used
in IVD software development, the structure can be used to create the first
process prototype for software development. Based on the different
requirements for different SSC’s, there needs to be separate processes for
each safety classification combinations. In addition to these also GPLE and
RUO processes needs to be defined.

Based on the device classification and the requirements defined in the QSR,
ISO 13485, and IEC 62304 the GPLE, RUO, SSC level A and LOC level Minor
can be combined to a single process, SSC level B can be combined with LOC
 37

level Moderate and SSC level C can be combined with LOC level Major. This
then produces three different process prototypes:

• Process 1: GPLE, RUO, SSC level A, LOC level Minor

• Process 2: SSC level B, LOC level Moderate

• Process 3: SSC level C, LOC level Major.

Detailed requirements for each process can be seen in Appendix 2.

The process used in the prototyping phase will be the Process 1. After
discussion with the customers stakeholders, most future projects will be
developed for GPLE and RUO only use so this would be the most beneficial to
be developed further. Process 1 will also enable the product to be conforming to
SSC level A and LOC level minor environments without major modifications.

Since the objective is to develop real life process to be used in production

environment, the different requirements and concepts can be converted to
required document or process to be included in the overall development
process. Based on the process descriptions derived earlier, it is now possible to
describe the process using process phase deliverables:

Process 1:

Design History File:

• Software Development Planning (Product Development Plan)

o Reference to QMS systems

o Reference to Risk Management

o Software Safety Classification/Level of Concern

o Software Risk Management Plan

o Software Configuration Management Plan

o Software Verification Plan

 38

• Software Development

o Software Product Requirements Document

o Software Hazard Analysis Document

o Software Unit Implementation

▪ Source Code (Version Control)

• Software System Testing

o Software Test Protocol/Test Set

o Software Testing and Verification Summary Report

• Software Trace Matrix

• Software Release Documentation.

Supporting processes:

• Software Maintenance Process

• Risk Management Process

• Software Configuration Management Process

• Software Problem Resolution Process

• Design Review Process.

5.2 Process Prototyping

After the data collection phase, the first prototype for stakeholder evaluation
was done. This first prototype was used for peer analysis in workshops to
gather information, improvement ideas and additional comments from
stakeholders to improve the first prototype. This is to make sure that all the
stakeholders from different areas have overall picture of the process to be
develop and how it would affect each of their software development areas. In
the next subchapters, implementation and structure of the workshops are
 39

defined. Expected outcome and changes implemented for the subsequent

workshop are explained.

5.2.1 Minimum Viable Process

The MVP is specification for the prototyping process which are required to be
achieved during the process development phase. The MVP is based on the
requirements defined in the Figure 3 where the high-level requirements are
introduced. The main specifications for the MVP are:

1. High-level process structure for software development phases.

a. Software Development Planning and Planning
Documentation.
b. Software Development and Development Documentation.
c. Software Development Reporting.
d. Supporting Processes and documentation.
2. Process implementation to ALM in tree form.

Outcome of the workshops should be high-level structure of the software

development process to be implemented into the ALM. The ALM uses task-
based structure, so all the process phases require individual or multiple tasks to
be defined to get all the required phases included on the overall process.
Starting point for the workshops is then derived from these specifications and
collected data built to the ALM test environment follows the initial prototype for
Process 1.
 40

Figure 5. Initial prototype built in the ALM environment.

 41

5.2.2 Workshop Structure

The first workshop session is structured to introduce the overall research, the
goals of the research project and overview of the new process prototype in high
level. Before each workshop session, agenda and the current prototype are
sent to the stakeholders to see the overview of the session and prepare for the
session beforehand. The structure and agenda for the sessions are:

Session 1 agenda (1h):

• Introduction for the overall research work.

• Presenting the minimum viable process.

• Overview of the process prototype.

• Change requests for the current process prototype.

• Conclusion and planning for the next session (if needed).

Subsequent sessions agenda (1h):

• Changes implemented to the process prototypes from previous

session.

• Feedback of the changes.

• Change requests for the current process prototype.

• Conclusion and planning for the next session (if needed).

Workshop sessions are stopped when no changes are requested in high level
and stakeholders are satisfied with the high-level process structure.

5.2.3 Workshop Sessions

The workshop sessions were held during the November and December of 2022.
After each of the pre-planned session, some time was reserved for
implementing the changes based on the discussions in the workshops and
 42

change requests rising from the individuals participating the meetings. All the
workshops followed the structure defined in section 5.2.2 and meeting minutes
were gathered during the sessions and then recorded after the sessions were
executed. All the meeting minutes can be found from Appendix 3.

The content and structure of the workshop sessions were as planned, and
many ideas and improvements were introduced during these meetings. All the
participants were motivated and willing to bring up their own ideas and views to
the discussions and to the process structure itself. The structure of the
workshops themselves was followed each time and since the structure was
identical in each session, the flow of the discussion was effortless. The
scheduled 1-hour time slot was adequate for most of the sessions but some of
the sessions might have benefitted from additional time. The final session did
not produce any major modifications of change requests so the participants
concluded that this would be the final formal workshop for this research.

Workshops were extremely helpful for building the process itself. Comparing to
the initial process prototype, multiple visual and structural changes were made,
more process phases were introduced to get more clear vision on how the
software development process fits the overall product development process.
There were also items missing from the initial process prototype which were
added during the workshops. All the generated actions points were executed
before each workshop sessions and shown to the participants during the
sessions.

All the invited participants contributed to the discussion in some level. More
project and process-oriented participants had a good view on the higher level of
development process and more technical people had a more detailed view on
the individual process steps and documentation themselves. This led to a good
discussion on how the process is formed in high level process and product level
and in detailed day to day software development level.
 43

5.3 Final Process Prototype

The final process prototype was finished after the workshop sessions based on
the gathered feedback. All the changes and ideas found during the workshop
sessions were gathered to the final process prototype. Each individual change
can be found from the Table 4.

Table 4. Changes to be made to the initial process prototype.

Workshop number Change

Hazard analysis added to

the process prototype

Differentiation and visibility for

RUO/GPLE and IVD made clearer

Workshop 1 Visualization tool changed from ALM to

Excel to add more visualisation while
prototyping

Trace to corresponding standards added

to the prototype

Added reviews for each document and

development phase needed

Software development plan to include

Workshop 2 checklist for each required phase for
RUO/GPLE and IVD

Software transfer process added to the

prototype
 44

Workshop number Change

Reviews reanalysed based on current

practises and made more visible in the
prototype

Technology assessment added to the

Workshop 3
prototype

All the development gates added to the

prototype to visualize the overall product
development

Added optional design description

specification to software development
plan
Workshop 4 (final)
Added the final process prototype to the
ALM system and share it with the
participants when done

The overall structure of the final process prototype remains similar to the
original. The software development planning process, software development
process, software verification process and software transfer and release
process and supporting processes are in the same place as in the initial
process. This is because the process itself relies heavily on the used standards
and changing the overall structure would make the traceability to standards
more difficult. Following the overall standard structure will make changing or
updating the process easier as standards are updated in the future. Unique
numeral identifier from 1 to 6 was also introduced to each process phase to
easily identify the process sequence and individual process phases and
documents. The phase also defines the document number for each document
for the current software project. Example of process phase can be seen in
Figure 6.
 45

Figure 6. Example of process phase in ALM.

There were some reviews identified in the initial structure but during the
workshops it was clear that more documents needed formal reviews in certain
phases of the application lifecycle. Required reviews were added to critical
documents and formal phase reviews including development phase review and
verification phase review. These phase reviews contain all the gathered
documentation and deliverables required for the specific phase and the purpose
is to finalize the previous process phase. Phase reviews and reviews for the
individual documents have unique symbol in the process which clearly
separates them from other documentation. Example of review can be seen in
Figure 7.

Figure 7. Example of review in ALM.

In addition to reviews, tasks are also introduced in the final process prototypes.
These tasks can be assigned to an individual who is responsible for that specific
document and contains template identifier which can be linked to a document
template. This template can be then used for that development phase to fulfil
the documentation requirements. Tasks are also indicated with unique icon in
the system, example can be seen in Figure 8.

Figure 8. Example of task in ALM.

 46

One topic in the workshop discussion was that requirements specific for IVD
software products only, needs to be differentiated from the RUO/GPLE
requirements. This was implemented using two methods: Software
development plan now includes checklist for what process phases and
documentation needs to be included for IVD product based on LOC and SSC
and what needs to be included in the for the RUO/GPLE software products.
These requirements need to be analysed and reviewed for each individual
software project, so this was added as a requirement for software development
plan. Second indicator for separating IVD from RUO/GPLE was to tag all the
phases, tasks, and reviews to indicate that some of the items were only
required for IVD software products, example of the “IVD only” tag can be seen
in Figure 9.

Figure 9. Example of process phase which is only required for IVD.

Supporting processes for the software development process remain mostly the
same. Design History File process was added to the list because it was required
for IVD and RUO/GPLE products. Unique document number was added to also
supporting processes so that the documentation can be easily identified. The
list and details of the supporting processes can be seen in Figure 10.

Figure 10. Supporting processes.

 47

The initial process prototype was used as a basis for the entire process and
used as a platform for the modifications. All the modifications shown in the
Table 4 were implemented into the final process prototype. Final process
prototype can be seen in Figure 11.

Figure 11. Final prototype built in the ALM environment.

 48

5.4 Sharing and Communicating the Results

After the workshops and finalizing the process prototype it was time for the final
analysis and sharing the results. Comparing the final process prototype to the
specification of the MVP shows that all the required items were achieved:

Table 5. MVP comparison with final process prototype.

Requirement Reasoning

High-level process structure was

achieved as shown in Figure 11. This
High-level process structure for
includes all the process phases required
software development phases
by the MVP from sections 1 to 6 and
supporting processes.

Software development planning and

Software Development Planning planning documentation was included in
and Planning Documentation the final process prototype containing
items in section 2.

Software development and development

Software Development and documentation was included in the final
Development Documentation process prototype containing items in
section 3.

Software development reporting was

Software Development Reporting included in the final process prototype
containing items in section 4.

Supporting processes and

Supporting Processes and documentation was included in the final
Documentation process prototype containing items
under supporting processes.
 49

Requirement Reasoning

Process implementation to ALM in Final process prototype tree structure

tree form was implemented to the ALM.

Comparing the MVP and final process, all the set goals were achieved and
additional details which were not required were also introduced into the
process. All stakeholders were satisfied with the result as a good starting point
to further develop the process and process details. After these conclusions, the
results were ready to be shared. Results in the ALM were shared with the
stakeholders participating the workshops and the audience was also later
expanded to include software management, software development team
members and project management.

Future for the process is to include expertise from quality management and
regulatory experts from different product areas to give independent advice and
opinions to the process itself and that the process is feasible to implement in
regulated and non-regulated environments. This involvement and development
would finally lead to official SOPs describing the overall process and individual
phases. This would also include creating work instructions on how to create all
the necessary documentation on practical level.
 50

6 Discussions and Conclusions

Working with different software development environments can be challenging

when considering regulated and non-regulated medical devices and general-
purpose laboratory devices. In general, developing non-regulated software does
not require so many strict processes and documentation as developing software
to IVD environments. To get the non-regulated software processes also
conform to IVD regulated processes, some changes need to be done. The main
focus of the thesis was to research what kind of changes need to be done to the
customer’s non-regulated software development process in order it to comply
with planned regulated IVD environment and what kind of processes and
documentation requirements needs to be put in place for this. As observed in
the background research phase the IVDR is recent update for the medical
device industry released in 2017 [6]. It was necessary to evaluate the processes
based on the latest regulation and latest standards and practices. Studies done
for the MDD (Medical Device Directive) and IVDD (In Vitro Diagnostic Directive)
regulated software development environments are now obsolete or at least
contain obsolete information.

During the current state analysis of the research, it was soon obvious that some
gaps were identified, and changes needed to be implemented for the current
process. The overall process however was similar between the two
environments and after the gap analysis it was soon clear that it was possible to
move from non-regulated environment to regulated one when concerning
software development. Since the current GPLE/RUO process was developed
based on ISO 13485:2016, the development process relied on current good
development practices but not as detailed as the IVD process documentation
which relied on more detailed IEC 62304:2006 standard. This showed that
using this standard is a good practice to also be utilized in other than regulated
environments. There were no major changes identified during the current state
analysis and data collection; some new processes and process phases and
some new documentation needs to be produced.
 51

In the workshop phase the whole team concluded that IVD processes and
GPLE/RUO processes can have similar process and documentation structure
with the latter having fever requirements. Based on this observation, the
process was constructed identical to both software environments but with
different streamlined requirements for certain phases as described in the final
process prototype. Stakeholders participating the workshops were satisfied with
the overall results stating that the prototype is a good overview of the used
process phases, documents and reviews included and consensus was that
further development is necessary for the prototype before it can be included in
the product development.

Since the final process prototype was developed and implemented based on
the most low-risk LOC and SSC categories, some additional work was left to be
done. There are multiple additional process and documentation requirements
for higher risk software which are not included in this research. However, this
needs to be researched and implemented in the future process prototypes to
obtain all the requirements included in the process. Second future improvement
would be also to cover clinical evaluations and usability evaluations as part of
the overall product development process. Since the focus was on software
development part, these requirements were left out. These should be
considered when implementing the overall process in the future. This research
was very tightly focused on creating process prototype and therefore future
development is necessary for it to be usable in production environments. All the
related processes and process phases need a SOP documentation which is
then referenced in the process. Template files for each specified document to
be included in the ALM must be designed and created. All these need to be
gathered into a single software development lifecycle procedure which can then
be taken officially into use after quality and regulatory approvals. One
interesting point during the prototyping phase was that software design
description is not required for lower risk software. The customer stated that it
was customary practice to document software design description for all software
products in some level but there was no common way to do this. This needs to
be investigated in the future to determine, does the customer want to produce
 52

design description for future projects even when it is not required for certain risk
levels.

Results and findings show that moving from non-regulated environments to

regulated can be achieved but requires a research work and high-level
standards and operating procedures be available for the whole product
development process. This kind of migration is highly dependent on the target
product environment and software development environment which may be
quite different between different manufacturers. Research framework used in
this thesis can be however applied to similar environments which are
considering regulated software development and are planning to release
product is similar regulated areas.

Migrating from software development environment to another can be a

challenging project especially in regulated environments. The research however
shows that it is very possible to use some areas of the current software
development process, add requirements from the regulations and combine
these to a single customizable software development process. Some areas
were left out from the research so that the focus is solely on the software
development process and the lowest risk category devices but adding these
later to the process can be achieved. Regulated environment requires more
process and deliverables than non-regulated but similar structure can be used
for both to streamline the development in software development teams involved
in different market areas. When the current development process is using
current good software development practices and relies on known standards, it
is easier to adapt to the regulated process but requires more time and effort
document and review individual documents and phases.

Overall, the research project was quite challenging but in the end rewarding.
The results were conclusive and the MPV was achieved, and expectations were
surpassed by getting additional content and information to the final process
prototype. Using the action research approach and especially workshop type
development cycles were easy way to analyse the process in iterations and
 53

motivated participants from several areas really helped to form the final result
which gave a great deal of insight to the author and also to the whole software
development team about processes in different environments.
 54

References

1 Regulatory and More. IVD vs. RUO.

<https://regulatoryandmore.com/2020/01/03/ivd-vs-ruo/>. Accessed 8 Nov
2022.

2 FDA. General purpose laboratory equipment labelled or promoted for a

specific medical use.
<https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?fr
=862.2050>. Accessed 23 Jan 2023.

3 Mertler C., A. Action research, Improving Schools and Empowering

Educators. 2020.

4 Weller J., The Complete Guide to Gap Analysis.

<https://www.smartsheet.com/gap-analysis-method-examples>. Accessed
1 Oct 2022.

5 Pitkänen H., Raunio L., Santavaara I., Ståhlberg T., European Medical
Device Regulations MDR & IVDR. Business Finland. 2020.

6 The European Parliament and the Council of the European Union,

"REGULATION (EU) 2017/746 OF THE EUROPEAN PARLIAMENT AND
OF THE COUNCIL of 5 April 2017 on in vitro diagnostic medical devices
and repealing Directive 98/79/EC and Commission Decision
2010/227/EU", 2017.

7 FDA. What does FDA do? <https://www.fda.gov/about-fda/fda-

basics/what-does-fda-do.>. Accessed 29 Sep 2022.

8 FDA/CDRH. Center for Devices and Radiological Health.

<https://www.fda.gov/about-fda/fda-organization/center-devices-and-
radiological-health>. Accessed 29 Sep 2022.
 55

9 FDA/CDRH. Overview of IVD Regulation. <https://www.fda.gov/medical-

devices/ivd-regulatory-assistance/overview-ivd-regulation>. Accessed 17
Nov 2021.

10 National Archives, Code of Federal Regulations. 21 CFR Part 809 – In

Vitro Diagnostic Products for Human Use.
<https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-809>.
Accessed 29 Sep 2022.

11 European Commission. Questions and Answers on the progressive roll-

out of the new In Vitro Diagnostic Medical Devices Regulation. <Q&A:
New In Vitro Diagnostic Medical Devices Regulation (europa.eu)>.
Accessed 29 Sep 2022.

12 FDA/CDRH. General Principles of Software Validation; Final Guidance for

Industry and FDA Staff, 2002.

13 Medical Device Coordination Group. Guidance on Qualification and

Classification of Software in Regulation (EU) 2017/745 – MDR and
Regulation (EU) 2017/746 – IVDR, MDCG 2019-11, 2019.

14 The European Parliament and the Council of the European Union,

“Summary of references of harmonised standards published in the Official
Journal – Regulation (EU) 2017/7461 of the European Parliament and of
the Council of 5 April 2017 on in vitro diagnostic medical devices and
repealing Directive 98/79/EC and Commission Decision 2010/227/EU”,
2022.

15 FDA. Proposed Rule: Quality System Regulation Amendments –

Frequently Asked Question. <https://www.fda.gov/medical-devices/quality-
system-qs-regulationmedical-device-good-manufacturing-
practices/proposed-rule-quality-system-regulation-amendments-frequently-
asked-questions>. Accessed 29 Sep 2022.
 56

16 National Archives, Code of Federal Regulations. 21 CFR Part 820 –

Quality System Regulation. <https://www.ecfr.gov/current/title-21/chapter-
I/subchapter-H/part-820>.

17 International Organization for Standardization, INTERNATIONAL

STANDARD ISO 13485:206 Medical devices – Quality management
systems- Requirements for regulatory purposes, 2016.

18 The European Parliament and the Council of the European Union,

“COMMISSION IMPLEMENTING DECISION (EU) 2020/439 of 24 March
2020 on the harmonised standards for in vitro diagnostic medical devices
drafted in support of Directive 98/79/EC of the European Parliament and of
the Council”, 2020.

19 FDA. Recognized Consensus Standards, Standards Designation Number:

62304.
<https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfstandards/results.cf
m>. Accessed 4 Oct 2022.

20 International Organization for Standardization, INTERNATIONAL

STANDARD IEC 62304:2006 Medical device software – Software life-
cycle processes, 2006.

21 FDA/CDRH. Guidance for the Content of Premarket Submissions for

Software Contained in Medical Devices, 2005.
 Appendix 1
1 (18)

Requirement Gap Analysis

Standard Requirements form QSR, Current state process Included in the IVD
No. Required Deliverable Analysis
/Regulation ISO 13485, IEC 62304 phase process

IEC 62304 4 General Requirements

 Appendix 1
2 (18)
Standard Requirements form QSR, Current state process Included in the IVD
No. Required Deliverable Analysis
/Regulation ISO 13485, IEC 62304 phase process

Reference to 13485:2016
Reference to
exists.
13485:2016
Current development Reference to QSR and IEC
Quality Management Reference to IEC
IEC 62304 4.1 process does not Referenced in planning 62304 is missing from the
System 62304:2006
reference the required current processes.
Reference to 21 CFR
quality management
Part 820
processes.

Reference to EN ISO Reference to EN ISO Risk management was

IEC 62304 4.2 Risk Management 14971:2019 Referenced in planning 14971:2019 referenced and included in the

Reference to ISO/TR Reference to ISO/TR planning.

 Appendix 1
3 (18)
Standard Requirements form QSR, Current state process Included in the IVD
No. Required Deliverable Analysis
/Regulation ISO 13485, IEC 62304 phase process

24971:2020 24971:2020
Reference to IEC Reference to IEC
62304:2006 62304:2006

Current process does not FDA Software Level of

Software Safety LOC or device safety
define Level of concern Specified in software Concern
IEC 62304 4.3 Classification/Level of classification is not defined in the
nor Safety class for the development planning IEC 62304 Safety
Concern current process.
software product. Class

Software Development
IEC 62304 5
Process
 Appendix 1
4 (18)
Standard Requirements form QSR, Current state process Included in the IVD
No. Required Deliverable Analysis
/Regulation ISO 13485, IEC 62304 phase process

Software Development Defined in the current process

IEC 62304 Defined Software Development Plan
Plan and required in the new process

Risk Management
Defined in the current process
IEC 62304 Software Development Defined Risk Management Plan Plan, Risk
5.1 and required in the new process
Planning Management Report

Not defined in the current

Software Configuration Software Configuration
IEC 62304 Not defined process and required in the new
Management Plan Management Plan
process
 Appendix 1
5 (18)
Standard Requirements form QSR, Current state process Included in the IVD
No. Required Deliverable Analysis
/Regulation ISO 13485, IEC 62304 phase process

Software Verification Defined in the current process

IEC 62304 Defined Software Verification Plan
Plan and required in the new process

Software Requirements Software Product Software Defined in the current process

IEC 62304 5.2 Defined
Analysis Requirements Document Requirements Analysis and required in the new process

IEC 62304, Software Hazard Software Hazard Defined in the current process
N/A Defined Software Hazard Analysis
QSR Analysis Analysis and required in the new process

Software Architectural Software Architecture Defined in the current process

IEC 62304 5.3 Defined Software Architecture
Design Document and required in the new process
 Appendix 1
6 (18)
Standard Requirements form QSR, Current state process Included in the IVD
No. Required Deliverable Analysis
/Regulation ISO 13485, IEC 62304 phase process

Software Product Software Product Software Product Defined in the current process
QSR N/A Defined
Specifications Specification Document Specifications and required in the new process

Software Detailed Software Detailed Defined in the current process

IEC 62304 5.4 Defined Software Detailed Design
Design Design and required in the new process

Defined in the current process

IEC 62304 Defined Source Code
Software Unit and required in the new process
Software
5.5 Implementation and
Implementation
Verification Software Unit Verification Defined in the current process
IEC 62304 Defined
Results and required in the new process
 Appendix 1
7 (18)
Standard Requirements form QSR, Current state process Included in the IVD
No. Required Deliverable Analysis
/Regulation ISO 13485, IEC 62304 phase process

Defined in the current process

IEC 62304 Defined Review Meeting Minutes
and required in the new process

Not defined in the current

IEC 62304 Not defined Static Analysis Results process and required in the new
process

Software Integration and Defined in the current process

IEC 62304 5.6 Defined Evidence of Integration Software Integration
Integration Testing and required in the new process
 Appendix 1
8 (18)
Standard Requirements form QSR, Current state process Included in the IVD
No. Required Deliverable Analysis
/Regulation ISO 13485, IEC 62304 phase process

Not defined in the current

Software Integration Testing
IEC 62304 Not defined process and required in the new
Results
process

Software Product
N/A Not defined Reviews for all the identified
Requirement Design Review
ISO 13485, documents are not defined in the
Design Review Design Review
QSR current process and required in
Software Product
N/A Not defined the new process
Specification Design Review
 Appendix 1
9 (18)
Standard Requirements form QSR, Current state process Included in the IVD
No. Required Deliverable Analysis
/Regulation ISO 13485, IEC 62304 phase process

Software Architecture
N/A Not defined
Design Review

Software Design Verification

N/A Not defined
Design Review

Not defined in the current

Unit test report for high
IEC 62304 5.7 Software System Testing Not defined Design Verification process and required in the new
relative risk units
process
 Appendix 1
10 (18)
Standard Requirements form QSR, Current state process Included in the IVD
No. Required Deliverable Analysis
/Regulation ISO 13485, IEC 62304 phase process

Defined in the current process

IEC 62304 Defined Software Verification Plan
and required in the new process

Defined in the current process

IEC 62304 Defined Software Test Protocol
and required in the new process

Not defined in the current

Software Test Protocol
IEC 62304 Not defined process and required in the new
Review Record
process
 Appendix 1
11 (18)
Standard Requirements form QSR, Current state process Included in the IVD
No. Required Deliverable Analysis
/Regulation ISO 13485, IEC 62304 phase process

Software Testing and Defined in the current process

IEC 62304 Defined
Verification Summary Report and required in the new process

Not defined in the current

Software Verification Report
IEC 62304 Not defined process and required in the new
Design Review Record
process

Not defined in the current

QSR N/A Software Trace Matrix Not defined Software Trace Matrix Traceability process and required in the new
process
 Appendix 1
12 (18)
Standard Requirements form QSR, Current state process Included in the IVD
No. Required Deliverable Analysis
/Regulation ISO 13485, IEC 62304 phase process

Not defined in the current

QSR N/A Design Validation Not defined Design Validation Plan Design Validation process and required in the new
process

Software Design and Defined in the current process

IEC 62304 Defined
Release Transfer Plan and required in the new process
Software Design
5.8 Software Release
Transfer and Release Not defined in the current
IEC 62304 Not defined Software Release Notice process and required in the new
process
 Appendix 1
13 (18)
Standard Requirements form QSR, Current state process Included in the IVD
No. Required Deliverable Analysis
/Regulation ISO 13485, IEC 62304 phase process

Not defined in the current

IEC 62304 Not defined Software build instructions process and required in the new
process

Software labelling (e.g., user

Not defined in the current
guide, release notes,
IEC 62304 Not defined process and required in the new
anomaly list, installation
process
instructions)
 Appendix 1
14 (18)
Standard Requirements form QSR, Current state process Included in the IVD
No. Required Deliverable Analysis
/Regulation ISO 13485, IEC 62304 phase process

Not defined in the current

ISO 13485,
N/A Design History File Not defined DHF Assessment process and required in the new
QSR
process

Software Maintenance
IEC 62304 6 Not defined
Process Software Maintenance, Software Maintenance Not defined in the current
Decommissioning and Process, separate process and required in the new
Establish software Disposal Plan process process
IEC 62304 6.1 Not defined
maintenance plan
 Appendix 1
15 (18)
Standard Requirements form QSR, Current state process Included in the IVD
No. Required Deliverable Analysis
/Regulation ISO 13485, IEC 62304 phase process

Problem and
IEC 62304 6.2 Not defined
Modification Analysis

Modification
IEC 62304 6.3 Not defined
Implementation

IEC 62304, Risk Management

Software Risk Risk management is not defined
ISO 13485, 7 Not defined Risk Management Process Process, separate
Management Process in the software development
QSR process
 Appendix 1
16 (18)
Standard Requirements form QSR, Current state process Included in the IVD
No. Required Deliverable Analysis
/Regulation ISO 13485, IEC 62304 phase process

documentation but in a separate

Analysis of software
product related documentation.
IEC 62304 7.1 contributing to
hazardous situations

IEC 62304 7.2 Risk control measures

Verification of risk control

IEC 62304 7.3
measures

Risk management of
IEC 62304 7.4
software changes
 Appendix 1
17 (18)
Standard Requirements form QSR, Current state process Included in the IVD
No. Required Deliverable Analysis
/Regulation ISO 13485, IEC 62304 phase process

Software configuration
IEC 62304 8
management Process

Configuration
IEC 62304 8.1 Software Configuration Not defined in the current
identification Software configuration
Not defined Management Process, process and required in the new
Management Process
separate process process
IEC 62304 8.2 Change control

Configuration status
IEC 62304 8.3
accounting
 Appendix 1
18 (18)
Standard Requirements form QSR, Current state process Included in the IVD
No. Required Deliverable Analysis
/Regulation ISO 13485, IEC 62304 phase process

Software Problem Not defined in the current

IEC 62304, Software Problem Software Problem
9 Not defined Resolution process, process and required in the new
QSR Resolution Process Resolution process
separate process process
 Appendix 2
1 (6)

Process requirements based on software environment, SSC,

and LOC

RUO / SSC A / LOC Minor

Design History File:

• Software Development Planning (Product Development Plan)

o Reference to QMS systems

o Reference to Risk Management

o Software Safety Classification/Level of Concern

o Software Risk Management Plan

o Software Configuration Management Plan

o Software Verification Plan

• Software Development

o Software Product Requirements Document

o Software Hazard Analysis Document

o Software Unit Implementation

▪ Source Code (Version Control)

• Software System Testing

o Software Test Protocol/Test Set

o Software Testing and Verification Summary Report

• Software Trace Matrix

• Software Release Documentation.

Supporting processes:

• Software Maintenance Process

• Risk Management Process

 Appendix 2
2 (6)

• Software Configuration Management Process

• Software Problem Resolution Process

• Design Review Process.

 Appendix 2
3 (6)

SSC B / LOC Moderate

Design History File:

• Software Development Planning (Product Development Plan)

o Reference to QMS systems

o Reference to Risk Management

o Software Safety Classification/Level of Concern

o Software Risk Management Plan

o Software Configuration Management Plan

o Software Verification Plan

• Software Development

o Software Product Requirements Document

o Software Hazard Analysis Document

o Software Architecture Document

o Software Product Specifications Document

o Software Unit Implementation

▪ Source Code (Version Control)

▪ Software Unit Verification Results

▪ Review Meeting Minutes

▪ Static Analysis Results

o Software Integration

▪ Evidence of integration

▪ Software Integration Testing Results

• Software System Testing

▪ Unit test report for high relative risk units

▪ Software Test Protocol/Test Set

▪ Software Test Protocol Review Record

 Appendix 2
4 (6)

▪ Software Testing and Verification Summary Report

▪ Software Verification Report Design Review Record

• Software Trace Matrix

• Design Validation Plan

• Software Release Documentation.

Supporting processes:

• Software Maintenance Process

• Risk Management Process

• Software Configuration Management Process

• Software Problem Resolution Process

• Design Review Process.

 Appendix 2
5 (6)

RUO / SSC A / LOC Minor

Design History File:

• Software Development Planning (Product Development Plan)

o Reference to QMS systems

o Reference to Risk Management

o Software Safety Classification/Level of Concern

o Software Risk Management Plan

o Software Configuration Management Plan

o Software Verification Plan

• Software Development

o Software Product Requirements Document

o Software Hazard Analysis Document

o Software Architecture Document

o Software Product Specifications Document

o Software Detailed Design

o Software Unit Implementation

▪ Source Code (Version Control)

▪ Software Unit Verification Results

▪ Review Meeting Minutes

▪ Static Analysis Results

▪ Software Integration

▪ Evidence of integration

▪ Software Integration Testing Results

• Software System Testing

o Unit test report for high relative risk units

o Software Test Protocol/Test Set

 Appendix 2
6 (6)

o Software Test Protocol Review Record

o Software Testing and Verification Summary Report

o Software Verification Report Design Review Record

• Software Trace Matrix

• Design Validation Plan

• Software Release Documentation.

Supporting processes:

• Software Maintenance Process

• Risk Management Process

• Software Configuration Management Process

• Software Problem Resolution Process

• Design Review Process.

 Appendix 3
1 (8)

Workshop meeting minutes

Workshop meeting 1: IVD/RUO/GPLE software development process

workshop kick-off

Attendees:

• R&D Software engineering manager, PC software

• R&D Software engineering manager, Embedded software

• R&D Software engineering manager, Project Organization

• Software Architect

• Product Owner

• R&D Manager, Product Lifecycle Management.

Agenda:

• Introduction for the overall research work.

• Presenting the minimum viable process.

• Overview of the process prototype.

• Change requests for the current process prototype.

• Conclusion and planning for the next session (if needed).

Notes:

• Introduction to overall research work, participants had questions about the

scope of the research and that was clarified.

• Minimum viable process was introduced, and scope was clarified even further.

• Initial process prototype was presented by going through each of the process
phases.

• Change requests and action points were introduced by participants.

 Appendix 3
2 (8)

o Scope clarifications (process based on 62304).

o Differentiating between RUO and GPLE.

o Ideas on how to include risk management analysis to the process

which has impact outside the software development.

• Next steps and action points were decided.

Action points:

• Hazard analysis review was missing from the process.

o Needs to be added to the prototype before next meeting.

• RUO/GPLE mandatory requirements to be more visible and included in the

process prototype.

o Add before next meeting.

• Use Excel to visualize the process more. This also adds ability to modify the
process more easily. Add also trace to ISO 9001, ISO 13485, and IEC 62304.

o Implement before next meeting.

Next meeting:

It was decided with the participants that next meeting will be arranged when
action points are implemented, and next free slot is available for all participants
within 2 weeks.
 Appendix 3
3 (8)

Workshop meeting 2: IVD/RUO/GPLE software development process

workshop 2

Attendees:

• R&D Software engineering manager, PC software

• R&D Software engineering manager, Embedded software

• R&D Software engineering manager, Project Organization

• Software Architect

• Product Owner

• R&D Manager, Product Lifecycle Management.

Agenda:

• Changes implemented to the process prototypes from previous session.

o New excel template for the process.
o Hazard analysis added as part of the process.
o RUO/GPLE mandatory requirements emphasised compared to the
regulated ones.
• Feedback of the changes.
• Change requests for the current process prototype.
• Conclusion and planning for the next session (if needed).

Notes:

• Changes to the process prototype were introduced.

• According to participants the overall process looks good.

• Discussion concerning various aspects of risk management between IVD and

RUO intended uses. It should be noted that IVD risk management focuses
more on patient and operator risks and RUO risk management should focus
on operator risks.

o This should be noted in the project development plan.

 Appendix 3
4 (8)

• Discussion on how reviews are managed in this process prototype.

o Review timing and needs to be evaluated.

• Change requests and action points were introduced by participants.

o Design transfer planning should be visible in the process.

o Software release process could be included in the software

development planning.

• Development plan should include checklist what is included in IVD/RUO

process.

• Next steps and action points were decided.

Action points:

• Which reviews are needed and in which phases of the process for each
deliverable?

o Needs to be added to the prototype before next meeting.

• Development plan to include checklist for each software process phase.

o Add before next meeting.

• Software transfer process items to be included in the overall development

planning.

o Add before next meeting.

Next meeting:

It was decided with the participants that next meeting will be arranged when
action points are implemented, and next free slot is available for all participants
within 2 weeks.
 Appendix 3
5 (8)

Workshop meeting 3: IVD/RUO/GPLE software development process

workshop 3

Attendees:

• R&D Software engineering manager, PC software

• R&D Software engineering manager, Embedded software

• R&D Software engineering manager, Project Organization

• Software Architect

• Product Owner

• R&D Manager, Product Lifecycle Management.

Agenda:

• Changes implemented to the process prototypes from previous session.

o Modified overall structure overview.
o Software transfer planning added to the Software Transfer and
Release Process.
o First draft of documents to be reviewed and review phases added to
the document.
• Feedback of the changes.
• Change requests for the current process prototype.
• Conclusion and planning for the next session (if needed).

Notes:

• Changes to the process prototype were introduced.

o According to participants, the overall structure looks better now.

o Software transfer plan is where it supposed to be in the process.

o Review process was discussed and some of the initial review points
are not in logical place.

▪ This should be reinvestigated.

 Appendix 3
6 (8)

• One participant noted that Technology assessment for software is not

included in the process prototype. This was that the assessment is outside
the currently specified phases.

o This should be added to the prototype.

• Discussion arose around the different gate phases in RUO and IVD
processes. It was requested that all the gates outside the software process
could be visible in the overall view of the prototype.

o These gates could be added to the overall process prototype.

• Next steps and action points were decided.

Action points:

• Recheck the reviews and modify the process prototype to show them more
clearly.

o Needs to be added to the prototype before next meeting.

• Technology assessment to be visible to the process prototype.

o Needs to be added to the prototype before next meeting.

• Add development gates outside the software development process just as

information to the reader.

o Needs to be added to the prototype before next meeting.

Next meeting:

It was decided with the participants that next meeting will be arranged when
action points are implemented, and next free slot is available for all participants
within 2 weeks.
 Appendix 3
7 (8)

Workshop meeting 4: IVD/RUO/GPLE software development process final

workshop

Attendees:

• R&D Software engineering manager, PC software

• R&D Software engineering manager, Embedded software

• R&D Software engineering manager, Project Organization

• Software Architect

• Product Owner

• R&D Manager, Product Lifecycle Management.

Agenda:

• Changes implemented to the process prototypes from previous session.

o Necessary reviews were revisited and shown more clearly in the
prototype.
o Technology assessment added to the process prototype.
o Development gates added to the process prototype outside the
software development process.
• Feedback of the changes.
• Change requests for the current process prototype.
• Conclusion and planning for the next session (if needed).

Notes:

• Discussion around design description in the process. Historically design

description has been a part of software development even though it is not
particularly required by either process. This was decided to be added as part
of software development plan to decide whether it is included in each software
product development process.
 Appendix 3
8 (8)

• In a final note, the participants agreed that this prototype was a good overview
of the processes and phases and a good continuing point to further develop
the process in more detailed level.

Action points:

• Add the final process prototype to the ALM system and share it with the
participants when done.

• Add optional design description specification to software development plan.

Next meeting:

It was decided with the participants the level of the process prototype is
sufficient at this point and that this workshop is the final one at this stage.