*3.9.1 Principles of coding*


Adhering to these principles may promote effective communication, collaboration, and quality assurance throughout the software development process.

*Quality Assurance When Developing Software with a Medical Purpose DOI: http://dx.doi.org/10.5772/intechopen.113389*

#### *3.9.2 Agile*

A life cycle is a process used to design, develop, and test high quality software. It consists of planning, requirement analysis, defining, designing, coding, testing, deployment, and maintenance. Agile approaches emphasize on continued collaboration and improvement. Tasks for a project are typically placed on boards to produce comprehensive overviews. The project is then divided into phases that each consist of planning, executing and evaluation. The advantage is that a large, complex project then consists of manageable chunks. Evaluation after each sprint improves collaboration and invites adjustments in the processes whenever this is necessary. As with the interpretation of the law, optimizations to processes are often recognized while executing them. Quality assurance departments recognize the need for corrective and preventive action but in practice only execute these after non-conformities are found. Though there is significant evidence that agile methods can be applied for developing software in the safety critical industry [36] and that this has significant benefits, organizations in highly regulated environments often lack suitability to accommodate fast response to changes. Processes may be dictated by standards rather than adapting methodologies to the company. The time and the energy that is needed to implement changes in processes is discouraging. So why would we still want to encourage agile methods? The obvious paradox is quality assurance itself.

Though the documentative culture caused by the need for compliancy to regulations and the fear for regulatory inspections [37] may prevent agile working, developing teams may still employ these methods to ensure the quality of the product. The idea is to create a process based on empirical logic that in the end fits into the defined logic of the company standards. This may create overhead for developers and lead to two track systems that then often requires syncing. Failure in doing so tends to make integration more difficult. The IVDR however is clear that we must attempt to take every action possible to minimize risks to the patient even if it means avoiding processes that are set in place due to that standard. Working agile in shorter sprints promotes quality because it limits the number of changes. If the software architecture has a strong domain-oriented architecture, it may prevent changes in one domain from affecting others. This focus minimizes the risks of introducing bugs because the scope of the changes is limited, and the effect are easily recognized. The scope of a cycle may for instance completely focus on interfaces, no changes in result data are then expected. In case discrepancies are found, they may be easily traced since the change set is limited and confined to a single domain. In comparison, if we choose to make a wide set of changes that affect analysis methods, configuration, and interfaces, then the complexity increases exponentially. The source of an issue may then be the result of changes in any of the domains or even be the result of unexpected interactions between these areas. Traceability may require rigorous investigation of possibly hundreds of changes to find the source of an error. Next to that, due to the increased length of a cycle, feedback from official testing may take such extensive periods of time that developers will need to invest time to get reacquainted with the topics at hand. Organization may also urge developers to continue working on a project before test results are produced. In those cases, changes may be placed on top of changes making traceability nearly impossible.

Shorter cycles may furthermore prevent scope creep, that is when new project requirements are added after the project execution has started. This has a major impact on project management and increases risks because these changes are often not properly reviewed, and developers are expected to complete the tasks with the

same resources and in about the same time as the original scope. This in turn leads to stress and frustration, it crushes enthusiasm and invites quick-and-dirty programming. This tactic of programming leads to serious deficiencies also known as the technical debt. We want to obtain all objectives, but we do not have the resources needed so priorities are reassigned, and certain objectives are postponed. We may for instance assume that, like in traditional development, QA teams run their tests and code is expected to have bugs and that as such developers only need to ensure that the code runs. When developing software for a safety critical industry cutting corners should be avoided. If QA becomes agile as well, they can work closely with developers, and each group can focus on different aspects of testing. Harmony and balance may reduce work and stress for both groups leading to higher quality products. Limited cycles also make it more acceptable for new project requests to be executed in the next cycle of development. Another way to prevent scope creep is by defining the requirements for a project, making a schedule for their execution, and then verifying the scope with the stakeholders. In that way an agreement may be reached that is verified by team members in stakeholders, in practice we may notice that unless officially verified, agreements tend to be easily mended.

#### *3.9.3 Software validation*

An important part of ensuring patient safety is sound risk/hazard analysis. Also, in software development it is an essential and required process to logically process for risk management from risk identification through evaluation, rating, and mitigation. International Society for Pharmaceutical Engineering (ISPE), ISPE's GAMP5 is a framework that provides a structured approach to validation that can be applied to agile development processes, as well as more traditional development patterns. GAMP is an acronym for Good Automated Manufacturing Practices, suggesting a scientific approach to enable the development of high-quality software that meet regulatory requirement and ensure patient safety. Standards such CE and FDA describe what needs to be done, but they do not describe how this must be accomplished. Protocols that are placed into effect by companies based on these standards often are translated one-to-one leading to inflexible systems that are document based on predefined logic that are inflexible to new implementations of context. The protocols are often also not defined by those who use them, leading to operational deficiency. Methods that are not adapted and made suitable for those who work with them, may lead to conflict, prevents innovation, decreases efficiency, and takes focus away from the core essential of the regulations: patient safety and product quality. The problem often lies with the absence of knowledge and experience with the specific matter at hand leading to demarking everything with the same priority and the idea that everything must be documented. The evaluation of risk to quality may instead be based on scientific knowledge and linked directly to the risk to the patient. In GAMP5 the level of effort, formality, and documentation of each process commensurate with the level of risk associated with that process. One could argue that this is the same as the benefit/risk analysis for all risks and the overall residual risk as required by the IVDR. GAMP5 has also been endorsed by the FDA as an acceptable approach to risk-based software development.

GAMP5 has a top-down approach that looks at processes before systems and operates from the notion that the risks associated with the computerized system cannot be greater that the risk associated with the processes it supports. When considering software for digitalMLPA, then the risk category for the software is thus directly

#### *Quality Assurance When Developing Software with a Medical Purpose DOI: http://dx.doi.org/10.5772/intechopen.113389*

linked to the digitalMLPA product that has the highest risk classification. When considering the relative risk level within the software, an initial assessment should be done that is based on an understanding of the processes, typically derived from the user requirements, design specifications, operating procedures, regulatory requirements, and functional areas as well as understanding of the behavior of the users. This information is then used to identify the specific functions that have impact on patient safety, product quality and data integrity. These functions can be identified as possible hazards and may require extra controls to minimize their harm. The rigor of the risk can be based on the impact of the function, note that no function can have a higher risk than its related process. Risk assessment can typically be done using the Failure Mode and Effects Analysis (FMEA**)** derived risk assessment processes, where severity and probability are set out against each other to obtain a risk class. The risk class is then plotted against detectability to obtain the priority class. High impact functions will often require mitigation, for instance by adding requirements for control systems, but they may also be warnings or constraints to limit behavior. Correct functional risk assessment requires a strong knowledge of the system, as well behavior of end users. It is also advisable to communicate mitigations with the final users to identify if the controls are suitable in practice. For example, a warning message that out of habit is directly closed by users without reading the information may not be a suitable control. Such behavior can only be discovered by direct contact with final users.

#### *3.9.4 Implementation and testing*

Based on the identification of the functions that have a certain severity and risk, tests may be developed to evaluate if the implementations meet expectations. For testing low level impact functions, we may suffice with validation of a user requirement. For digitalMLPA software we may want to validate that a user is able to produce a log report, such low impact requirement meets compliancy if they match normal business expectations. Medium impact level functions need consideration of failure mode and typically involve the creation test case scenarios. These test scenarios describe use cases and their expected outcomes. For digitalMLPA we may for instance want to have a test case scenario where a user has specified incorrectly which digitalMLPA product was used. The digitalMLPA software has a control that matches the set digitalMLPA product to the automatically recognized digitalMLPA product. The test in the implementations when executed by a user must then show that a user was able to correctly identify the problem when using the software. Such outcome may involve subjective reasoning, since a user need to identify that there is a problem and what that problem entails. This may thus lead to the need to install extra controls or adjustments to the chosen implementation. For high impact functions specific risk scenarios must be tested. For digitalMLPA software, we may for instance expect that there are probes in probe mixes that are used to detect DNA mutations that are used when considering the diagnosis of a patient. Note again that the highest risk class cannot be higher than the risk class of the software. Under the IVDR that would automatically indicate that use cases that involve diagnosis of a patient are only appropriate if that software was distributed and intended to be used with a digitalMLPA product that has an intended purpose to influence the diagnosis. High impact level functions should be rigorously tested to ensure that the appropriate response is generated. For digitalMLPA this may involve creating test scenarios that involve evaluation of the appropriate response when reference signals are absent for these mutation probes or what happens if the

settings in the configuration are incorrect. Based on the outcome of the tests, controls may need to be applied to increase robustness. Controls and their test results should be retraceable to their original risks. Risk assessment is typically repeated periodically and in case the risk class changes, for instance due to the installment of a higher class digitalMLPA product in the configuration of the software, then appropriate measures and controls need to be installed that match the impact level. The higher the risk level of the function, the greater the controls that should be applied. For digitalMLPA software when analyzing a mutation probe that has the highest impact level, we may for instance set in place a requirement that to analyze that probe in a test sample, we need in that same experiment both a positive sample and a negative reference sample. Such samples may then be used to establish the expected outcome under the same circumstances allowing higher confidence when calling a result in an unknown test sample.

An alternative strategy to estimate the necessary level of testing and investigation of the impact level of each function is by using the V-models (**Figure 3**).

In V-models often the depth is related to the risk class. As such low impact user requirement only need performance qualification. This usually entails requirement analysis, unit implementation and system testing (Class A – Level 1). Medium impact user requirements obtain functional specifications and perform both performance and operational qualification. Here design documentation is extended with architectural design and testing is extended with unit verification and integration testing (Class B – Level 2). High impact user requirements then also include the lowest layer of technical design specification and verification of these specifications (Class C – Level 3). Each step is followed by risk assessment, as well as evaluation of test results and installment of controls whenever needed.

It may be worth mentioning here that software designated for digitalMLPA cannot produce any data on its own, similarly a digitalMLPA product cannot produce useful output without specialized software. The product digitalMLPA, thus consist of the probe mix kit, the software and the service or support provided. A user requirement

**Figure 3.** *Example of a product validation pattern.*

#### *Quality Assurance When Developing Software with a Medical Purpose DOI: http://dx.doi.org/10.5772/intechopen.113389*

of a product may then for instance be the ability to detect certain types of Duchenne muscular dystrophy. Associated risks when performing such an analysis may be that incomplete denatured DNA can show patterns that resemble deletions of copy numbers. Control mechanisms may thus be set into place to measure incomplete DNA denaturation by adding specific probes that are targeting GC% rich areas that will show early signs of denaturation issues. The functional tests to ensure such a control system works appropriately could be established by calibration series for that product using samples with increased salt concentrations. These salt concentrations will make it incrementally harder for the DNA to denature. We then want the control system to pass off a warning long before entering the process of copy number estimation related to disease diagnosis. However, the only way to measure this feature is to have specific software that can fulfill the needs related to the specific control mechanism. In this case the software is thus in direct association with the user needs of the overall product and the validity of the control mechanism can only be tested by the combination of the two elements. Controls should always be traceable to their original identified risks, and residual risk evaluation must be performed after installment of the selected controls for all high-risk functions. We may thus recognize that due to the associative actions between a digitalMLPA product and its related software, there may be many different V-models and that the depth of these models may be multilayered. Such multilayered systems can be executed in stages that have their own specific models for evaluation. The required depth should however be associated with impact level which is always related to the overall risk level associated with the intended use of the product as specified by the manufacturer. digitalMLPA software should fulfill the data analysis needs of many digitalMLPA products that may have different demands depending on the type of product. To do this, the system does not alter its original functionalities but rather allows adaptation of values that are assigned to certain variables to fulfill the needs of different users in the context of their processes. The risk level of the software itself should thus be related to the risk level of the digitalMLPA product that has the highest risk level. Please note that even though digitalMLPA products may use the software as a type of control that exists on a single level for the digitalMLPA probe mix, that we would still recommend multilayers testing and installment of controls for the software itself.

#### *3.9.5 Review and monitoring*

Once software requirements are verified and controls are implemented, they require monitoring. Implemented controls can reduce testing efforts, eliminating the need for calibration series with different salt concentrations for each digitalMLPA probe mix once we confirm that the installed controls function effectively across multiple mixes. Assuming the control configuration remains unchanged, residual risk analysis should be conducted to ensure the adequacy of controls. Periodic evaluation is necessary to identify new, unrecognized risks and determine if recognized hazards, their estimated risk levels, and controls remain appropriate.
