Engineering High Quality Medical Software: Regulations, standards, methodologies and tools for certification
![image of Engineering High Quality Medical Software: Regulations, standards, methodologies and tools for certification image of Engineering High Quality Medical Software: Regulations, standards, methodologies and tools for certification](/docserver/fulltext/PBHE012Emedium.jpg)
No longer confined to medical devices, medical software has become a pervasive technology giving healthcare operators access to clinical information stored in electronic health records and clinical decision support systems, supporting robot-assisted telesurgery, and providing the technology behind ambient assisted living. These systems and software must be designed, built and maintained according to strict regulations and standards to ensure that they are safe, reliable and secure. Engineering High Quality Medical Software illustrates how to exploit techniques, methodologies, development processes and existing standards to realize high-confidence medical software. After an introductory survey of the topic the book covers global regulations and standards (including EU MDD 93/42/EEC, FDA Title 21 of US CFR, ISO 13485, ISO 14971, IEC 52304, IEEE 1012 and ISO/IEC 29119), verification and validation techniques and techniques, and methodologies and engineering tasks for the development, configuration and maintenance of medical software.
Inspec keywords: medical computing; certification; standards; software quality
Other keywords: risk management; certification; quality management; project management; high quality medical software engineering; software as a medical device; standards
Subjects: Biology and medical computing; Software engineering techniques; General and management topics
- Book DOI: 10.1049/PBHE012E
- Chapter DOI: 10.1049/PBHE012E
- ISBN: 9781785612480
- e-ISBN: 9781785612497
- Page count: 295
- Format: PDF
-
Front Matter
- + Show details - Hide details
-
p.
(1)
-
Part I: Introduction
1 Introduction
- + Show details - Hide details
-
p.
1
–15
(15)
Introduces the topics covered by the book and the introductory concepts. It clarifies what is medical device software, what is not, and emphasizes the differences between the new categories of medical device software and the classic medical devices. It also introduces regulations, standards, and practices. The need for medical software compliance is explained. The aim of this book is to explore this complex scenario and to illustrate how to exploit techniques, methodologies, development processes, and existing standards to realize high-quality medical purpose software, according to the regulations. The certification of SaMD is the goal of the engineering tasks illustrated in the book.
-
Part II: Regulations
2 EU MDD 93/42/EEC
- + Show details - Hide details
-
p.
17
–30
(14)
Council Resolution 85/C 136/01 of the May 7, 1985 defined the so-called “new approach” to technical harmonization and standards with the aim of removing barriers to trade and facilitating the free movement of goods within the European Union (EU). In the health-care domain, the effect of such a resolution had been the definition of a legal framework for medical devices that consists of three directives: (1) Council Directive 90/385/EEC on Active Implantable Medical Devices (1990) [7]; (2) Council Directive 93/42/EEC on Medical Devices (1993) [8]; and (3) Council Directive 98/79/EC on In Vitro Diagnostic Medical Devices (IVDMD) (1998) [9]. Therefore, such a legal framework had been originally conceived in order to “remove barriers to trade and facilitate the free movement of medical devices.” The effort of harmonization, however, had resulted in the definition of a set of common requirements for safety, which had previously been defined separately by the Member States.
3 FDA title 21 of US CFR
- + Show details - Hide details
-
p.
31
–42
(12)
In accordance with its mission, “The Food and Drug Administration (FDA) in the USA is responsible for protecting public health by assuring the safety, efficacy and security of human and veterinary drugs, biological products, medical devices, food supply, cosmetics, and products that emit radiation.” The FDA is also responsible for advancing public health by helping to speed up the progress of innovations that make medicines more effective, safer, and more affordable and by helping the public to obtain the accurate, science-based information they need to use medicines and foods to maintain and improve their health. The FDA also has responsibility for regulating the manufacturing, marketing, and distribution of tobacco products to protect the public health and to reduce tobacco use by minors. Finally, the FDA plays a significant role in the national counter-terrorism capability. It fulfills this responsibility by ensuring the security of the food supply and by fostering the development of medical products to respond to deliberate and naturally emerging public health threats.
4 Regulations for other markets
- + Show details - Hide details
-
p.
43
–50
(8)
The Therapeutic Goods Administration (TGA) controls medical devices in Australia according to criteria prescribed by the Therapeutic Goods (Medical Devices) Regulations 2002. The regulatory environment in Australia is quite similar to that in Europe. Indeed, if a device has the European CE Marking, the classification will probably be consistent and the approval process will be easier since the CE Marking is generally accepted by the TGA.
-
Part III: Standards
5 ISO 13485: medical devices - quality management systems - requirements for regulatory purposes
- + Show details - Hide details
-
p.
51
–67
(17)
ISO 13485 (medical devices-quality management systems-requirements for regulatory purposes) is an international standard that presents the requirements for a quality management system specific for the realization of medical devices, including software systems with medical purposes. For the reminder of the chapter, we will refer to ISO 13485:2016, which is the latest available version of the standard.
6 ISO 14971: medical devices - application of risk management to medical devices
- + Show details - Hide details
-
p.
69
–85
(17)
The paper discussed the ISO 14971 standards. ISO 14971 is an international standard for risk management specifically devised for the development of medical devices. The standard is intended to help manufacturers to establish a full risk-management process that includes the identification of hazards, the assessment of the related risks, and the implementation of risk control measures.
7 IEC 62304: medical device software - software life-cycle processes
- + Show details - Hide details
-
p.
87
–93
(7)
IEC 62304 is a framework of life-cycle processes, with activities and tasks, which focuses on the design and maintenance of safe medical device software.
8 IEEE 1012 and ISO/IEC 29119: standards for software verification
- + Show details - Hide details
-
p.
95
–105
(11)
IEEE standard 1012 [33] focuses on verification & validation (V&V) processes and applies to systems, software, and hardware being developed, maintained, or reused (e.g., Commercial Off-the-Shelf (COTS) components). V&V processes include the analysis, evaluation, review, inspection, assessment, and testing of products. V&V may be performed at the level of the system, software element, or hardware element, or on any combination of these. V&V may also be performed on an element of a system, including a subordinate system (i.e., subsystem). In each case, the V&V processes are invoked, either in parallel or recursively, across the full life cycle of the system or element.
-
Part IV: Verification and validation techniques
9 Static testing
- + Show details - Hide details
-
p.
107
–120
(14)
Verification is the activity relating to the evaluation of the software system in order to determine whether the product of a given development phase satisfies the requirements established before the start of that phase. The focus is on building the product correctly. Validation, instead, concerns the evaluation of the software system in order to determine whether the product meets its intended use. The focus is on building the correct product. Testing is one of the best tools to verify and validate a software system.
10 Dynamic testing
- + Show details - Hide details
-
p.
121
–136
(16)
Dynamic testing (or dynamic analysis) aims at verifying the dynamic behavior of a system. It encompasses the design and execution of test cases. Although the design of a test case can already be performed in the early stages of the development of the software system (e.g., the acceptance tests), the execution, and thus the verification of the behavior, can, of course, be performed only after the system has at least partially been realized. In other words, dynamic testing needs the software to have been compiled and executed with some specific input values and internal conditions in order to compare the obtained results with those expected. In the following sections, we are going to discuss how to design, create, and execute dynamic testing.
11 Formal verification
- + Show details - Hide details
-
p.
137
–146
(10)
Formal verification is another way to check several quality characteristics of a system. The aim is to explore all the possible states of the system to check for properties of interest such as safety (nothing bad will happen), liveness (something good will happen), and fairness (independent subsystems make progress), or common design flaws such as deadlock (the system should not reach a state in which no further action is possible), and livelock/starvation (when a subsystem is prevented from taking any action because of resource contention).
-
Part V: Techniques, methodologies, and engineering tasks for the development, configuration, and maintenance
12 Prescriptive software development life cycles
- + Show details - Hide details
-
p.
147
–159
(13)
The term software applies to computer programs, procedures, and documentation and data pertaining to the operation of a computer system. It is a product of the human manufacture. However, it's different from all other kinds of product manufactured by humans because of a few peculiarities. In the remaining part of the chapter, the most relevant software development strategies and prescriptive development process models are presented.
13 Agile software development life cycles
- + Show details - Hide details
-
p.
161
–172
(12)
The paper discussed the development of software system life cycles. The Agile Software Development Alliance emerged during a 3-day work meeting held on February 2001 in Utah, where 17 methodologists finally summarized their ideas about new ways of developing software systems and managing related projects in the Agile Manifesto. The Agile Alliance is not a sect of anarchists who intend to subvert “the established order” of traditional prescriptive methods. Rather, it is a group of methodologists, intensely engaged in software development, which aims to bring out “higher value” through agile methods.
14 Project management
- + Show details - Hide details
-
p.
173
–187
(15)
In accordance with the definition provided by the Project Management Institute (PMI), “a project is a temporary endeavor undertaken to create a unique product, service, or result.” Every project must create either a completely new or an evolved release of a product, service, or result. Every project must have a certain degree of uncertainty in the result, final quality, time, or cost. Otherwise, it is not a project. The project has a planned beginning and end, therefore, a definite life-cycle. It may be closed as a consequence of one of the following events: (1) the project's objectives have been achieved; (2) the project's budget (money and/or time) has been consumed, without reaching the objectives, and it is not possible or expedient to increase it; (3) the client requires to terminate the project; (4) the project's objectives can no longer be met; or (5) there is no longer any need for the project. The PMI has also defined project management as “the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.”
15 Risk management
- + Show details - Hide details
-
p.
189
–207
(19)
This is a book chapter that discusses a risk management approach based on Probabilistic Risk Assessment (PRA). PRA is defined as a systematic and comprehensive risk assessment methodology used to identify and evaluate risks in each life-cycle phase of complex engineered systems across different industry sectors (e.g., chemical, avionics, aerospace, etc.). The classic PRA approach involves techniques such as fault tree (FT) and event tree (ET), which leverage a Boolean logic to describe the formation of system failures by means of basic events. The accuracy of this approach decreases when the retrieval of probabilistic information about failures is difficult. However, it is still used to compare evaluated risks with predefined risk rankings in order to support improvement during the system design and development phases.
16 Requirements management
- + Show details - Hide details
-
p.
209
–218
(10)
A requirement of a software system is a characteristic that the system should have, a functionality that it should support, or a constraint that it should hold. A formal definition was provided by IEEE Std 610.12. Requirements engineering is the process of finding out, analyzing, prioritizing, documenting, checking, and tracing. On the other hand, the introduction of faults at the engineering requirements phase may be very costly. Boehm performed one of the first cost studies to determine the cost factors associated with fixing defects. The cost increases up to 100 times when the defect is found late in the operation phase.
17 Design controls and development management
- + Show details - Hide details
-
p.
219
–231
(13)
Design controls are management practices such as policies, processes, and procedures that apply to control design activities. The goal is to control the design process in order to ensure that the system specifications meet the user needs and intended use.Design controls must be set up for a new product after the completion of the project-initiating phase and before the project-planning phase; that is, once it has been determined that the product is feasible and the decision to start the project has been taken. The real essence of design controls is to provide evidence that the system has been designed to be safe.
18 Test management and defect management
- + Show details - Hide details
-
p.
233
–244
(12)
Before presenting some software testing management strategies and methods, it is worth introducing the seven fundamental principles of software testing, which have been established over several years of experience. These principles can be used as a guideline for both software testing and coding activities.
19 Change management, configuration management, and change management
- + Show details - Hide details
-
p.
245
–254
(10)
In software maintenance, it is quite common to identify another type of software change, namely Preventive changes, because code can have flaws that are not real defects (they do not cause failures), but they make the software harder to maintain in the future. Preventive changes are those that improve the maintainability of a software system or reduce the potential for future failures.
-
Part VI: Conclusions
20 Conclusions
- + Show details - Hide details
-
p.
255
–265
(11)
The global market for Information Technologies in health care is experiencing and will continue to experience a dramatic development according to the predictions of the most quoted study centers. bbcResearch evaluates the Compound Annual Growth Rates (CAGR) for IT spending to increase until 2019 by 4.8%, whereas MedGadget estimates a CAGR of 6.0%.
-
References
- + Show details - Hide details
-
p.
267
–270
(4)
Back Matter
- + Show details - Hide details
-
p.
(1)
Related content
![Loading](/images/jp/spinner.gif)