Clinical risk evaluation of medical device software: an axiomatic design-based methodology

The increasing complexity of medical device (MD) management software requires the adoption of new methodological approaches that pay particular attention to safety issues. The risk analysis is one of the key activities to be carried out by the manufacturer before the development of the software application as it determines the type of documentation to be provided as well as the activities to be performed to place the MD on the market. After the definition of software requirements and their iterative transformation into architectural items and/or units, the manufacturer defines the safety class of each item. The adoption of an axiomatic design approach facilitates this process. This combination of techniques helps to focus the design of medical device software on non-conformities with a clear link to clinical risk. This objective can be achieved by assessing the complexity of the system to be designed, both in terms of its functional size, and as a level of overall clinical risk. In this multi-dimensional perspective, the software effort expressed in function points provides an estimate of the development cost. While the clinical risk analysis allows to quickly identify critical areas, to intervene with the same promptness and to draft a management plan according to the regulations of the various control authorities.


Premise
Clinical risk is the probability that the patient will suffer unintentional damage or discomfort, due to health care, that causes an extension of the period of hospitalization, a worsening of health conditions or even death [1][2]. Medical devices are often made up of heterogeneous components that interact with each other. These are hardware, software and mechanical parts designed to perform specific tasks. The analysis of the risks associated with possible malfunctions follows the entire development cycle of the device [3]. This analysis covers all its components. It is even more effective if the various components are functionally decoupled. This means that the attribution of various user requirements can refer uniquely to a single part of the device. In this sense, Axiomatic Design is a design methodology particularly suitable for defining the overall mapping of risks associated with the user of a specific device and for optimizing the patient flow [4]. This allows to easily detecting the specific non-conformity, during the functional decomposition phase, by analyzing the conditions of non-compliance of the functional requirement. In any case, the management of past anomalies for similar procedures provides a significant support at this stage, particularly if the non-conformities have been catalogued and analyzed in Holistic Non-Conformity Reduction mode [5,6]. Moreover, the axiomatic approach allows to define an interdomain association that keeps specific users together, functional requirements traced back to a specific user requirement [7,8]. This leads to the definition of a project in which the individual component, at any level, can be traced back to a specific user requirement. This mapping among different domains allows to associate the risk of malfunction occurring with a multi-dimensional perspective. However, at the same time, the mapping makes it possible to decouple the areas of application [9]. Thus, the solution to a precise problem can be sought in a specific area. Each intervention on the system involves a distinct implementation tool or by redefining the functional requirements of the system to be designed. It also involves an overall redefinition of the axioms of independence and information. While the axiom of independence allows the identification of a logically coherent design solution, the axiom of information allows the selection of the design solution with a lower information content [10]. This is equal to defining the least complex solution.

Scope of application
In this paper, we propose to introduce an axiomatic methodology of risk analysis related to the use of software operating on medical devices (MD). The proposed approach is an extension of the Axiomatic Design of Object-Oriented Software Systems (ADO-OSS) methodology [10,11]. The process of identifying and managing risks takes place throughout the entire life cycle of the software [3]. Axiomatic Design can be used to define the logical design of the system from high user requirements [12]. The application of the axiom of independence remains unchanged. This axiom guides the decomposition of functional requirements until the identification of the detailed design of the system so that the programmers can develop the system. The axiom of information, on the other hand, is applied on a multidimensional perspective. This perspective allows to carry out several evaluations at the same time. By using function point analysis first, we can evaluate the estimate in terms of function points of the software to be estimated [13,14]. However, we can also estimate the probability that the single component of the system could present a malfunction in the use phase (O). In the same way, we can attribute to the various elementary components of the system the probability that the same non-conformity will be detected (D), as well as provide with an estimate of the impact on patients and health workers (S). This information can be used to feed risk re-composition techniques such as Fault Tree Analysis (FTA) [15] and Health Failure Mode and Effects Analysis (HFMEA) [16,17]. These techniques are particularly suitable for mapping possible situations of non-compliance of systems, allowing the start of activities to minimize the overall risk [18][19][20][21]. In this way, the axiomatic approach not only allows to design a software system that is logically consistent with the functionality to be performed but the system itself will be robust with respect to processing complexity and risk analysis associated with the occurrence of a malfunction. In this paper, we will closely monitor the application of this axiomatic approach, in the specific case, of the implementation of a software for the management of a drug infuser. For this case study, an approach based on axiomatic design is proposed to facilitate the identification of possible malfunctions and consequently contribute to the reduction of clinical risk [18,22].

Clinical risk management related to software malfunction
Risk management follows the entire product life cycle [3]. It represents the set of corrective and preventive actions aimed at eliminating and/or mitigating the occurrence of risky events in a system [23,24]. In the field of medical devices, these events can also have very serious consequences for patients and operators. For this reason, the competent supervisory authorities in Europe and the Food and Drug Administration (FDA), in United States, have issued guidelines on the risk analysis of medical devices. Furthermore, manufacturers are obliged to subject these devices to a conformity assessment to demonstrate that they meet the legal requirements to ensure that they are safe and work as intended. Conformity assessment usually involves an audit of the manufacturer's quality system and a review of the manufacturer's technical documentation on the safety and performance of the device [3]. These security certificates are addressed to the product, but also to its individual components, such as software. [3].

Introduction to the HFMEA methodology
The HFMEA methodology is particularly suitable to allow the building of a management plan for the clinical risks associated with a specific medical device [23,24]. HFMEA analysis is usually carried out using brainstorming techniques within multidisciplinary teams. Each team member brings his or her own expertise to a continuous exchange of ideas and design solutions. In its conventional formulation, HFMEA is launched since anomalies historically detected in the system for similar procedures or identified during testing. The following coefficients are determined for each possible anomaly or fault [25]:  Coefficient of gravity of the selected event (S);  Coefficient associated with the probability of occurrence of the malfunction (O);  Coefficient of detection of the event itself (D). These coefficients are estimated by the members of the multidisciplinary team based on specific tables, which consider the operating context of the software to be implemented. They form the basis for calculating an overall risk coefficient for the malfunction, called RPN (Risk Priority Number). [22]. The HFMEA analysis distinguishes between an "As is" phase, which represents the current state of risks associated with the system, and a "To be" phase. This second phase represents the state of the system after the introduction of improvements aimed at minimizing the overall value of the RPN coefficient. In fact, for each failure detected during the "As is" phase, one or more actions will be identified to allow its resolution. Each action will be associated with the working group responsible for its execution. Then, the RPN (Risk Priority Number) will be re-determined according to the adoption of the particular action taken. The whole process is cyclical. It is completed when the overall RPN value that is considered adequate to commercialize the product is achieved, and in any case when all nonconformities of high severity are eliminated or made predictable.

Axiomatic Design of Object-Oriented Software Systems
The management of risks associated with the release of a software system in the medical field can be carried out following an axiomatic approach. This approach is particularly well suited to the operating environment. In fact, it could be easy to extend this analysis, also, to the mechanical and hardware components of the medical device. In this way, the causes of malfunction could be verified, depending on the interactions among different components. Moreover, it should be noted that the Axiomatic Design (AD) methodology was created in the manufacturing sector [26]. It was later extended to other sectors, such as the design of information systems. Unlike other engineering sectors, the implementation of software systems is strongly conditioned by the creativity and experience of its designers. In this context, AD provides an approach based on quantitative measurements and comparisons that, if correctly applied, can guide designers to identify optimal implementation solutions. Suh [10,11] proposed a methodology for developing information systems called Axiomatic Design of Object-Oriented Software Systems (ADO-OSS). It combines object-oriented programming techniques (OOP) and AD design. OOP is a programming paradigm, in which a system is conceived as a set of objects that interact with each other. Each object is constituted by a set of attributes and functions, called methods. The set of several objects is defined as class [12,13]. With this methodology, Suh [10] pointed out that programming techniques can be optimized by preceding the software implementation by a conceptual model of system built based on AD decomposition techniques of the relations functional requirements and data structures. This process was formalized in the socalled model V of Figure 1. It is based on the application of the axioms of independence and information. The independence axiom ensures that the decomposition performed is logically consistent, while the information axiom sets an upper limit to the level of complexity of the system, as a minimization of the information processed by the system.

Considerations around the information axiom for applications with high safety standards
In order to allow risk management over the entire life cycle of the software, it is necessary to extend the application of the information axiom. Other cases of reformulation of the Information Axiom as a multicriteria analysis tool are available in literature. The approach proposed by Kulak et al. [25] is very interesting. They propose a combination of AD and fuzzy logic analysis as a tool to support decision-makers in the healthcare field. In this specific case, however, the proposed methodology works mainly in the software design phase. In fact, the proposed reformulation of the Information Axiom allows identifying the parameters required to implement an effective and efficient clinical risk analysis strategy. This extension does not operate on the axiom of independence, whose application remains unchanged. In the software field, the common use of the information axiom is very limited [13]. Often its application can be perceived as a cost in terms of resources used to produce documentation, probably even useless. Especially in the field of agile programming, it is preferable to neglect its applicability. As far as the health-care sector is concerned, overall, the variable cost of the software project has a lower priority than the safety standards that the final product must guarantee. For a non-critical management project, the application may be put into production, starting with a prototype that partially covers the required functions and with a test plan that has not been fully executed. Patients and operators cannot be endangered in the healthcare sector. In Europe and the United States, vigilance authorities oblige MD manufacturers to high levels of safety [3]. This means that the applicability of the axiom of information becomes again not only economically advantageous, but above all necessary. The application of axiomatic decomposition involves a mapping process among three conceptual domains of Figure 2 [9]. In this context, the operational specifications of the device constitute the customer attributes (CA) of the process. Below, we can define MD use cases as high level functional requirements (FR). Design parameters (DP) are created by designers. They correspond to the collaborations (interactions) among various Use Cases. In this way, the first level decomposition describes the network of interactions among Use Cases [9,12]. This network of interactions is graphically represented by a design matrix. This matrix allows to set the evaluation of the information axiom with respect to a pair of parameters (FP, S). While function points (FPs) can be calculated since functional requirements (FRs) [27,28], the coefficient of severity associated with the non-execution of the selected functional requirement (S) can be estimated based on a matrix of evaluation of the severity of the clinical risk introduced in 2003 by the Italian Ministry of Health [23,24]. Finally, we can set the process variables (PV) to coincide with the applications of libraries that implement the functionalities to be implemented. They represent the tools of software implementation. The correlation matrix between Physical domain and Process Domain lays the foundations for a second evaluation of the information axiom with respect to the pair of parameters (O, D). The coefficient of occurrence of the malfunction (O) is related to the reliability of the technical solution to be adopted. Instead, the detection coefficient (D) of the malfunction depends on the possibility that the error is detected before it produces substantial damage to the patient. Both parameters can be estimated since clinical risk assessment matrices introduced in 2003 by the Italian Ministry of Health [23,24].

Axiomatic decomposition
The axiomatic design is a top-down design. It continues with successive decompositions of functionalities up to a level of detail that enables its implementation by developers. In the last stage of decomposition, the decomposed functional requirements (FR) are elementary functions, while the design parameters (DP) are data sets, corresponding to the objects of the upper classes [9][10][11][12]. Instead, the project variables (PV) are codes, algorithms, subroutines, machine codes, compilers to accomplish the DPs [10,11]. The building of mapping matrices is carried out through a multiple zigzagging process among tree domains, as shown in Figure 2. This multiple zigzagging process has the advantage of decoupling the analysis of the different design aspects.

Evaluation of the information axiom as a multi-criteria analysis
The interdomain mapping process involves the evaluation of the information axiom with respect to four different parameters (FP, S, O, D). Table 1 illustrates how to apply the information axiom with respect to the two interdomain mappings in Figure 2. In short, this configuration allows the execution of a multi-criteria analysis. The information axiom becomes the tool not only to minimize the information complexity in function points, but also to design a system with a lower risk level than the HFMEA parameters (S, O, D).

General outline of the process
At this point we can present the general scheme of the process that combines these two methodologies. This mixed approach follows a general scheme of type V model ( Figure 3). The axiomatic decomposition of functional requirements feeds the HFMEA process of identifying the software failure modes. Instead, the evaluation of the clinical risk is the activity of recomposition of these failure modes, with a reverse process. A team of multidisciplinary experts can provide an estimate of the impact of the elementary failure modes with the final patient. In the same way, the improvement actions aimed at reducing the RPN coefficient follow the same path, from the bottom to the top of Figure 3. The process is overall iterative. It is interrupted when a solution is considered acceptable with respect to the performance and safety standards, required to receive marketing authorization from the competent control authorities (Safety class) [3].

Syringe infusion pumps
Infusion pumps are one of the most widely used medical devices in healthcare facilities [29]. They control the infusion of liquid drugs into the bloodstream or may allow the patient to be fed artificially by means of a probe. For this case study we have taken as reference the general structure of the syringe pumps. This type of infuser is intended for the controlled administration of liquids through a mechanical tool (syringe). The infusion rate is set by the healthcare professional [29]. These pumps can use the syringe piston to calculate the reciprocity between the controlled rectilinear displacement and the infusion rate. A screw under the syringe allows the amount of fluid injected to be precisely adjusted to allow for an almost continuous flow. The mechanism is started by a direct current electric motor. The main difference between this and the other devices lies in the ability of the syringe pumps to infuse very low quantities of fluid simply by replacing the syringe used and thus the capacity of the device. It is measured by the control device in terms of volumes per unit of time. In these pumps the flow control is based on methods of measuring the viscosity of the liquid.

Syringe infuser components
A syringe infuser consists essentially of two fundamental components: the pump and a syringe ( Figure 4) [29,30]. The two components are connected to each other by a special cannula, called outflow. The pump is a hardware device with a control software system. The syringe is, on the other hand, a mechanical instrument.

Fault alerts
Standard EN 60601-2-24 states that in the event of an anomaly being detected, the infusion pumps must activate a visual and acoustic alarm signal [31]. The visual signal must be continuous, while the acoustic signal may be intermittent with a duration of not less than two minutes. Healthcare professionals cannot intervene to disable these signals. For syringe pumps, the main detectable anomalies are the following: incorrect syringe insertion; occlusion; pressure level; pressure drop; end of infusion; end of stroke; prolonged pause; insufficient battery charge; pump malfunction [30,31]. Therefore, the device management software must also process signals relating to mechanical and electrical components.

Use cases associated with the infuser management process in pediatric oncology
In the diagram shown in Figure 5, the main use cases of the general scenario relating to the home administration of drug infusion are highlighted. The operational context concerns pediatric oncology. Furthermore, the actors of the process are identified. They are the device operator and service center. The device operator can be a healthcare professional or a child's parent. The following use cases reported represent the high-level functioning of a generic syringe infuser in this specific operating context:

Axiomatic decomposition of use cases
Axiomatic design allows to proceed to a decomposition of the functional requirements in terms of cases of use of the system. This decomposition can be extended to define the logical design of the system. This level allows programmers to initiate the software implementation process. For the sake of brevity, we will not proceed with further decompositions. For the same reason, we will neglect the estimation of the size of the software in terms of function points. The use cases of the previous paragraph (3.2.1) can be represented by the design matrix of Table 2. This matrix is built by placing the use cases along the lines of a square matrix. The corresponding columns show the reciprocal collaborations or interactions [9,12]. At this point, we assume the following condition: a collaboration is only possible if the case of use indicated in the column of the matrix activates any event, which changes the status of the case of use indicated in the corresponding row. The cells that show a collaboration between use cases show the symbols S ij . These symbols measure the risk class of the specific processing or interaction between use cases. For example, S 11 is the risk class associated with initialization of the infusion process (FR1). However, S 31 represents the risk class of the event generated by the use case FR1 that triggers processing in the use case related to purging operations (FR3). Table 2. Design matrix of use cases related to general scenario of Figure 5 in home pediatric oncology w

Application of independence and information axioms for the project matrix of use cases
First functional level corresponds to FR0. It is the management of the infusion process for a syringe pump. For the sake of simplicity, we do not consider the mode of functional decomposition in the use cases shown in Figure 5. We refer this in-depth to the existing literature on the subject [9,12]. Therefore, let us start again from the evidence that the applied functional decomposition led us to the matrix in Table 2. This matrix is triangular. Therefore, the axiom of independence is respected. With regard to the axiom of information, we must provide an estimate of the parameters of severity of the clinical risk (S ij ) associated with a possible malfunction of the device.
Taking as reference what is prescribed by the Decree of the Italian Ministry of Health of March 5, 2003 [23, 24], we can attribute to S ij whole values ranging from 1 to 5. The rules for assessing the level of severity of clinical risk are defined by the ministerial Table 3.

Functional decoupling
The functional decomposition of paragraph 3.2.3 can also be reversed as a mapping between the Physical domain and the Process domain. Following the diagram in Figure 2, we can construct the matrix of application interventions in Table 4. This matrix shows the interactions of the design matrix in Table 2 along the rows. Not necessarily or not only through software applications, it is possible to execute the use cases that have been defined in advance. If we consider the specific case of a syringe infuser, the administration of the drug can also be very accurately regulated with a mechanical instrument. Often this type of infusion is combined with special syringes that use a manual regulation of the flow by means of a screw. In other cases, sets of syringes are supplied that are calibrated to allow the administration of specific drugs with specific speeds. The matrix in Table  4 shows as an exclusively mechanical solution the execution of the case of use related to the administration of the drug (Administer drug Tool). In other situations, the implementation interventions concern the development of software procedures (App). This is possible because the axiomatic methodology allows the decoupling between the functional side, represented by the design matrix of the use cases (Table 2) and the implementation side of Table 4 [9]. The matrix of implementation actions shows the solutions to be adopted, regardless of whether it is a software procedure, an electronic device or a manually adjustable mechanical mechanism. Of course, the whole design process is iterative. Therefore, the adoption of a specific solution can change the configuration of the functional requirements [9].

Axioms of independence and information application to the project matrix of implementation measures
As for paragraph 3.2.3 we restart from the evidence that the matrix is triangular in Table 4. Therefore, the axiom of independence is respected. As far as the information axiom is concerned, the entropy of the system can be evaluated with respect to a pair of values (O ij , D ij ). O ij represents the probability that the single implementation intervention can be a cause of malfunction. D ij is the level of detection of the same malfunction. Both parameters of the pair (O ij , D ij ) can assume integer values varying from 1 to 5. Table 5 and Table 6 illustrate the rules for assigning evaluation scores for both parameters. Both tables transpose the requirements of DM 5 March 2003 on clinical risk management [23,24]. Table 5. Matrix for evaluating the occurrence of a malfunction for a device or apparatus in the health sector [24]

Clinical risk assessment
The axiomatic decomposition of use cases enables a robust infuser design to be defined. This design includes both the electronic components, the management software and the mechanical parts. Each of these specific components is, down to the most basic level of detail, linked to a specific functional requirement. This overall mapping allows us to identify possible operational criticalities and to reconfigure the project itself, in order to minimize its occurrence. The overall process is iterative. It is based on the application of the axioms of independence and information. In particular, the information axiom allows to associate the complexity of the system to the Risk Priority Number (RPN). Therefore, the designer's objective is to minimize the value of RPN. This iterative process stops, when the preset clinical risk mitigation goals are achieved. These goals must guarantee, at least, the safety standards set by the control authorities to obtain authorization for the marketing of the medical device in its entirety. However, the manufacturer can set a higher product quality level than the service levels set by the guidelines of the authorities. In this case, we have that: Clinical risk mitigation goals = FR satisfied / resources spent [32]

Construction of the HFMEA matrix
The construction of the FMEA matrix is the final act for the definition of the clinical risk management plan. Table 7 illustrates how to analyze the malfunction associated with the occlusion of the outflow. This problem is associated with the case of use related to the administration of the drug (FR2). The effects are related to discontinuation of treatment. The indicators of severity (S), detectability (D) and probability of occurrence (O) should be estimated based on the specific treatment for which the device is intended [3]. The corrective actions to be taken concern the use of a sensor that controls the flow of the drug. In the event of an occlusion, the management software must activate visual and acoustic alarms that cannot be deactivated by healthcare professionals. Only the resolution of the problem can disable the alarm [31]. FMEA also identifies the person responsible for the problem resolution intervention. In this case, this is a situation that must be managed by the healthcare professionals who are treating the patient using the infuser.

Conclusions
In this context, Axiomatic Design is the most appropriate tool to allow the integrated design of a device consisting of non-homogeneous components. This is possible because the axiomatic methodology allows the decoupling between the functional side, represented by the design matrix of the use cases (Table 2) and the implementation side of Table 4. The implementation matrix shows the solutions to be adopted, whether it is a software procedure, an electronic device or a manually adjustable mechanical mechanism. Of course, the whole design process is iterative. So, the adoption of a particular solution can change the configuration of the functional requirements. This same process makes it possible to build a clinical risk management plan based on the information axiom. This axiom allows the complexity of the system to be assessed since the Risk Priority Number (RPN). This assumption allows us to simultaneously implement an infuser control software application and build a clinical risk management plan.