This chapter provides an overview of quality management systems (QMS). There is an increasing emphasis of regulators on the “organization” as opposed to the “product,” which places an even greater emphasis on the use of a QMS. We first introduce what a QMS is (Section 4.1) and provide some regulatory background, including a discussion of the recent FDA precertification program.

This chapter presents an introduction to risk management, a core regulatory requirement for all medical software. We begin with an overview of the regulatory background (Section 5.1) and then review both the international standard ISO 14971:2019 and a recent guidance document from the IMDRF. Next, we describe the process of risk analysis (Section 5.2), including issues related to the use of artificial intelligence/machine learning (AI/ML) techniques.

This chapter provides some basic background on selected topics in software engineering. This should be useful for those readers whose background is primarily in basic science and engineering, who may have not been previously exposed to this type of material. This chapter is meant to complement the introduction to mathematical topics presented in Chapter 8.

This chapter describes the software design document. This is the first step in the software life cycle where we leave the abstract plane and begin to think more concretely about the product. The structure of this chapter is as follows. First, we discuss (Section 13.1) that we are at the point of creating a bridge from the system requirements to the actual code.

This chapter presents the “business” view of medical software. It takes a company to bring an idea to market and, ultimately, clinical use. We begin with a brief description of issues related to entrepreneurship (Section 6.1): Should somebody who has a promising idea consider starting a company on their own?

On Monday, February 3, 2020, the results of the Iowa Democratic Party Caucus, the first caucus in the US election cycle, were delayed as a result of bugs in the software used to report the results. This software (the IowaReporterApp) was not properly tested prior to the elections, and the whole reporting system failed during the event.

This chapter presents an example medical software life cycle process. We first introduce the topic (Section 10.1), and introduce our example project – the image-guided neuro-navigation system – that we will use to illustrate the process over the next few chapters.

Much of the work involved in the development of medical software (and in particular the process of software validation) depends critically on an understanding of topics such as probability theory, statistics, and increasingly machine learning. The goal of this chapter is to provide students with some theoretical grounding in this general area.

The changeover from 1999 to 2000 introduced a major risk of system failure in computer systems worldwide. This had to do with older software’s use of two-digit numbers to store the year. As the year (in two digits) moved from 99 to 00, there were serious possibilities of many systems failing. This resulted in a huge effort to fix this problem across multiple major computer systems.

This chapter describes the process of creating a system requirements document which is one of the most important steps in the software life cycle. First, we orient ourselves as to our position in this life cycle (Section 12.1). Next, we present a brief review of key regulatory issues (Section 12.2), and following this we describe a template for creating this document (Section 12.3).

This chapter begins by defining what medical software is and what makes it unique, and describing the regulatory process that governs it (Section 1.1), including a brief introduction to industry standards. Following this, we discuss the constraints (both business and technical) placed on the software process by the medical environment (Section 1.2).

This vignette describes the accidental destruction of a multi-million-dollar outer space satellite, primarily due to inconsistency of mathematical units used in different components of the system. Poor fault analysis, decision-making, integration testing, and auditing led the Mars Climate Orbiter to burn up in Mars’ atmosphere, never to be contacted again.

This chapter describes the regulatory process for medical software, with a particular emphasis on the documents issued by the United States Food and Drug Administration (FDA). We first describe the FDA itself (Section 2.1), including a brief history of how the current process has evolved over the past century.

This chapter describes software construction and testing. These are the very concrete steps in the software life cycle (Section 14.1). Next, we discuss “construction,” or coding (Section 14.2), beginning with a brief review of key regulatory issues. We follow this with a presentation of programming topics and conclude this section with an extended discussion of risk management in the context of the programming process.