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?

In this chapter, we distinguish funding liquidity from market liquidity, and idiosyncratic liquidity from systemic liquidity. We discuss the nature of highly liquid assets, and methods by which a firm might acquire liquid assets to cover short-term cash flow problems, either in normal operations, or in more extreme crises. As liquidity risk is a problem of cash flow management, we explain how cash flow scenario tests can be used to identify and mitigate risks. We describe liquidity adjusted risk measures used in banking. Finally, we describe how firms might create emergency plans for managing extreme and unexpected liquidity shocks.

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.

The chapter begins by examining why the EU regulates, beginning with how the EU attempts to justify its regulatory power before exploring the main principles underlying EU regulation. We will then focus on who regulates in the EU, that is, the institutions, such as agencies and committees, that assist the EU in achieving its regulatory goals. The remaining sections will focus on the questions of how the EU regulates, distinguishing between the main legal and non-legal tools by which the EU regulates, and the judicial routes available to enforce or challenge the validity of such regulatory choices. Throughout, the focus will lie on the tension between efficiency and diversity that drives EU regulatory choices.

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.

This chapter explores whether we can (and should) think of the EU as a unitary system or as one that allows for internal differentiation and layering, both in terms of the horizontal relationship between the EU Member States and the one between the EU and non-EU states. The chapter highlights the legal methods of differentiation, such as enhanced cooperation and opt-in and outs, and analyses the limits and pathologies of differentiating EU obligations. It also looks at the different models of differentiation that are available, beginning with the process of joining and leaving the EU, before moving on to think about the interaction between the EU and the EEA, the United Kingdom and the role of Free Trade Agreements. As we will see, the question of which model of cooperation to choose, or of how differentiated the EU should be, once again poses fundamental trade-offs between sovereignty and unity that ultimately depend on how we understand the EU’s purpose.

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.