**3. The pathway**

The IVDR introduces a risk-based approach to classification, it is like the MDR in that it takes a lifecycle approach to IVD regulation. It also incorporates many elements of the current European guidance documents and concepts such as performance evaluation (with a major emphasis on clinical performance), vigilance and post market performance follow-up. The first step in the development of medical software, is to determine the class as it will highly influence the pathway to obtain accreditation which in turn influences how software should be developed and e.g., determines post market requirements. Besides, one may choose specific strategies that may make the progress easier and take steps that help to integrate the process into the organization. As such, the demonstration of conformity through technical files and records, quality systems and clinical evidence & performance may become a wide carried process and includes input from business executives, members of the data management team and workers throughout the whole line of development. By harmonizing the development of software and the required documentation they may work in synergy and time and effort may be spared.

#### **3.1 digitalMLPA & software**

To classify digitalMLPA software, it's important to understand its usage alongside digitalMLPA products. digitalMLPA probe mixes consist of probes targeting specific genomic sequences, comprising a Left Probe Oligonucleotide (LPO) and a Right

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

Probe Oligonucleotide (RPO). LPO contains a P7 Polymerase Chain Reaction (PCR) primer and a DNA hybridization sequence, while RPO includes a sequence for distinct digitalMLPA read identification and a DNA hybridization sequence. Hybridized probes that can bind to target sequences are ligated and amplified with a single primer pair, making MLPA robust for copy number assessment. The MLPA reaction involves mixing a minimum of 20 ng DNA sample with 2 ul of a unique barcode solution. After denaturation at 98°C for 10 minutes, 1.25 μL digitalMLPA probe mix and 1.25 μL buffer are added to each sample. Probes are then hybridized overnight at 60°C, saturating all target sequences in the DNA sample. Oligonucleotides are ligated enzymatically, incorporating a barcode oligo for sample identification. The ligase is inactivated by increasing the temperature to 98°C for 5 minutes and incubated at 65°C for 20 minutes to reduce background. Ligated probes are amplified using a single P7/ P5 primer pair in a multiplex PCR, removing the need for unbound and non-ligated probes. The PCR-amplified products are quantified using an Illumina sequencer by utilizing the Rd1 sequence, which serves as the Illumina tag. The resulting data is stored in FASTQ files, a text-based format for biological sequences and quality scores. An average FASTQ file size is 23 Gb, containing approximately 25 million read sequences in a 7.5 Gb file. Specialized data analysis tools are required to analyze such data and provide a viable user experience that allows interpretation and give meaning to the results.

#### **3.2 Classification**

Here we describe possible classifications based on deductions using the provided information the EU has granted on the IVDR. Classification rules may vary based on regional regulations, intended use of the software and the different countries or regulatory bodies that may have their own classification systems. It is thus recommended to consult regulatory authorities or guidelines in the relevant jurisdiction for a more precise classification, we only wish to give an outline here. The IVDR uses seven rules for classi4ication along with guidance as provided by the Medical Device Coordination Group (MDCG 2020-16 Rev.2) on implementing the rules to help manufacturers to identify the risk class of the IVD devices. Assuming a riskbased position, classification starts by assuming the highest: Class D (detection of the presence of, or exposure to, a transmissible agent and/or working with infectious loads of a life-threatening diseases) or products that pose a high public health risk. The standard then tones down to Class A, products for general laboratory use which possess no critical characteristics (receptacles, buffer solutions, washing solutions, and general culture media). Guidelines to software classification follow more specific guidelines as laid out by MDCG 2019–2111. The starting point is setting out the devices, intended purpose, from which it can be determined whether it is a medical device and if it is, what the classification may be.

Software itself can be defined as a set of instructions, that processes input data and creates output data. Medical software is software intended to be used, alone or in combination, for a purpose specified in the definition of a "medical device" in the MDR or IVDR, regardless, of whether the software is independent, driving or influencing the use of a device. Medical devices are products or equipment intended for a medical purpose. This seemingly, simple question can be quite complex, and heavily related to the intended purpose that is assigned to the product, which a manufacturer should describe in detail to understand whether there is a medical action involved. In

the European Union's Regulation (EU) they rely on No. 2017/745 on Medical Devices Regulations (EU MDR) and Regulation (EU) No. 2017/746 on in vitro diagnostic devices (IVDR). Software may be considered a medical device if it's intended by the manufacturer to be used alone or in combination, for human beings for one or more medical purposes such as: diagnosis, prevention, monitoring, prediction, prognosis, treatment or for providing information by means of in vitro examination of specimens derived from the human body, including organ, blood, and tissue donations. Not all software in healthcare is qualified as medical software, simple search and retrieval of records does not qualify as medical software, but software intended to process, analyze, create, or modify medical information may be qualified as a medical device software. We may also need to consider whether the software is a companion diagnostic or an accessory. Companion diagnostics only provide information for the use of a product and accessories indicate that the medical device can be used independently even in the absence of an accessory; neither seem to be true for software intended to analyze digitalMLPA data. MLPA data analysis software may be described as a molecular diagnostic tool as it aids in the interpretation of genetic data for diagnostic purposes. MLPA is often used in clinical genetics, cytogenetics, and research settings to identify genetic mutations or chromosomal abnormalities associated with various genetic disorders.

Once it is established whether the software is a medical device, then it needs to be considered whether it is an In Vitro Diagnostic Medical Device Software (IVD MDSW) or Medical Device Software (MD MDSW). IVD MDSW falls under the in vitro diagnostic medical devices Regulation (EU) 2017/746. In case the MDSW creates information based on data obtained by a vitro diagnostic medical device or if information provided is based on data, obtained solely from in vitro diagnostic medical devices, then it is an IVD MDSW. Software that takes raw data outputs and uses clinical algorithms for diagnostic and/or prognostic purposes also qualifies as a IVD MDSW. The IVDR requires that all existing and new IVDs are (re)classified based on a risk-based classification system [27]. Finally, the risk class may be considered that is applicable. This categorizes the risk of software, based on the combination of the significance of the information provided by the software to the healthcare decision and the healthcare situation or patient condition. We may for instance consider, that the software is used in combination with a medical device, that provides information on the statistical predisposition of Down syndrome (Trisomy 21), may be classified as Class IIb, since it may lead to an irreversible deterioration of a person's state of health. If the software is used to determine the etiology of intellectual disability and developmental delay to inform neurologists, geneticists, pediatricians, and patients' families, then the class would likely be Class IIa. The IVD class influences the requirements and assessment routes, and the required development process documentation needed to demonstrate that all requirements have been fulfilled, as for instance indicated by IEC 62304. A supporting approach to the documentation process that may be interesting for software development is Good Automated Manufacturing Practice (GAMP), GAMP 5, which is a science-based approach to understanding and managing risk for computerized systems that resembles the International Electrotechnical Commission (IEC), IEC 62304. These standards both suggest that for Class IIb and Class C devices should have detailed software design documentation while this is not necessary for Class IIa and Class B devices. Class I and Class A devices on the other hand only require planning, setup of user requirements and validation of those requirements and do not require architectural design specification, unit testing and integration testing, which is necessary for Class IIa and Class B devices and up.

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

If we want to make software for a product that is currently Research Use Only (RUO) oriented but as a future product has the intend to be a medical device, then one may argue that prudence entails both long-term preparation and short-term, goal-oriented planning. Quality assurance comes from due diligence in all stages of production. As such, we may choose to take up a higher classification initially as it will be easier to come down later, rather than to first built a high mountain and then attempting to climb it. Such decisions are however highly dependent on purpose, context, meaning, organizational structure, availability, priorities, and support by a wide range of members of the data management team, stakeholders, business users and business executives. If a team prefers to build a tool that will never be used for a medical purpose, then extensive documentation may be superfluous. Problems with documentation may become a complication that brings frustration and struggle. While documentation and code serve different goals, without documentation code is not a full-fledged product. Choosing an approach that is well thought through and supported through the whole line of development is therefore essential to the success of any project.

#### **3.3 Innovative diagnostics**

The IVDR recognizes the need for different types of products by admission of the clinical need for laboratory developed tests, In House IVD tests (**I**H-IVD), modified CE-IVDs, RUO tests, and off-label use, if their benefit for patients is obvious and can be proven. IH-IVD can be used by diagnostic laboratories if they meet several conditions and requirement as specificized by IVDR article 5.5. The IVDR thus explicitly states, that its requirement does not apply to IH-IVD, with exception of the relevant General Safety and Performance Requirements (GSPR) if several conditions are met [27]. Health institutions must justify that the specific needs of a group of patients cannot be met, at a desired level of performance by an equivalent device on the market that is a CE-IVD. Judgment of equivalence is up to health institutions, and they should have documented justification for their use of IH-IVDs, competent authorities only oversee compliance of health institutions notified bodies with respect to article 5.5. Justification, however, is a continuous responsibility and thus requires laboratories that have implemented IH-IVD to regularly monitor and evaluate new CE-IVDs. This extra work on its own, may be an incentive for replacing or marking IH-IVD through the industry. How equivalence is exactly determined, and what is expected in terms of comparison of performance, is open to speculation. In the absence of exact specifications what needs to be done, we may get started without delay. Epistemologically, for abstract ideas and beliefs to become more concrete, experience with the matter is necessary, which can only be obtained by doing the actual work. The implementation of the regulations may thus follow a similar iterative process where the final interpretation may only become clear while the law is applied. Innovative diagnostics are therefore typically expected to be first developed and applied locally, in healthcare institutions with specific expertise and then taken over by IVD manufacturers that produce above certain volumes, to make the tests cost effective.

When considering MLPA in its early development, we may see that this technique was first introduced in 2002 by MRC Holland as a research technique which then, among others obtained validity as a classifier [28] and as a technique to investigate copy number aberrations [29]. Through the years of usage and by experience via many validation studies it was able to confirm its performance. The IVDR also

mentions that: "if a device is in a performance evaluation phase, it can be made available to institutions or laboratories to be subjected to one or more evaluations studies, with the intend to gather information on performance evaluation parameters" as mentioned in Annex I of the directive. This information can then be used for its conformity assessment. This would require the manufacturer to draw up a statement that the device conforms to the requirements of the directive, apart from those specifically itemized in the statement and that every precaution has been taken to protect the health and safety of the patient, users, and other persons. When IH-IVDs developed and used by the academic diagnostic sector make it into commercialization, other problems may arise, such as lack of interest by manufacturers due to economic viability and/or access patient-derived material for controls. In-house devices shall not be transferred to another legal entity, which thus entails that health institutions that manufacture in-house devices may only use those device within that same legal entity. Since a legal entity may be a single hospital or several hospitals that are part of one health institution, collective development of IH-IVDs may greatly reduce regulatory burden, as well as increasing access patient-derived material for controls. This may in turn lead to improvement of quality and standardization of tests. Access to patientderived material may be one of the main factors preventing transfer of IH-IVDs to CE-IVDs, especially for rare disease and why it is nearly impossible for manufacturers to directly develop CE-IVD tests. Other factors include complexity, suitability for automation, algorithm dependence as well as a variety of national diagnostic and reimbursement practices that affect economic viability [23].

#### **3.4 digitalMLPA RUO tests**

Products designated for RUO are exempt from MDR and IVDR regulations, and if used solely for research purposes, they are not considered in-house devices. Common genetic disease research has already established knowledge on copy number variations using methods like conventional MLPA, array Comparative Genomic Hybridization Arrays (CGH), Single Nucleotide Polymorphism (SNP**)**, SNP genotyping, and nextgeneration sequencing [30]. RUO products developed for research purposes typically fall into the category of general laboratory use, serving as elements in diagnostic testing plans to assess their potential future use in IVDs. digitalMLPA, as a screening technique, offers advantages such as replacing multiple MLPA assays with a single test, reducing costs and turnaround times, and targeting specific genomic targets without extensive NGS kit requirements. It ensures deliberate and purposeful testing to reduce ambiguity surrounding patient problems and prevents misleading disease associations. With its simplicity, low cost, target specificity, rapid detection of CNAs in up to 1000 target sequences, digitalMLPA is well-suited for diagnostic purposes. Furthermore, once development and quality control processes are established, new digitalMLPA products can be easily developed, including targeting niche diseases overlooked by commercial companies.

digitalMLPA data results cannot be interpret without specialized software, that can import FASTQ files and convert the sequence data into understandable results, that include meaning and significance for a variety of context dependent situations. MRC Holland, as the internal user, needs software for data analysis and quality assessments of digitalMLPA products and are therefore an important group of target user for which the software should be developed. We may expect that digitalMLPA will target areas for investigative research, such as the usage of copy number data for genomic profiling and their correlation to medicine effectiveness. The potential for

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

molecular-guided therapy to affect the treatment of an individual patient has been recognized [31] and digitalMLPA may be a product that may aid in recognition of patients where such therapies may be beneficial. Especially in understanding cancer development and progression, next-generation sequencing has played an important role, and therapies that target a cancer's genomic dependencies has fueled the transition of genomic assays into clinical use [32]. Users of RUO products may therefore be, an important second line of users. While these products may initially be developed and used to investigate specific purposes, through usage and experience they may end up as IH-IVDs or as part of an IH-IVD device. We may also have users that already use conventional MLPA as a diagnostic tool or users that are in search of diagnostic tools and are evaluating how NGS devices may aid in lowering costs and improve turnover times. Typically, much of scientific software development, is carried out by scientists who create programs to support their investigations [33]. When software development is not done by scientists themselves, establishing requirements may be difficult considering that the goals in question are potentially unknown. In such cases it is particularly important to gather understanding of the environment, practices, technologies and wishes that potential and future users may have.

#### **3.5 User surveys/pre-market research**

Understanding of the user environment of potential customers is an essential step in an early phase of development since it may for instance lead to constraints to the resources a software program may depend upon. Software for digitalMLPA will need to work with FASTQ files which may very large files up to 100 Gb. If 8 GB is the standard amount of RAM for your average desktop computer in 2022, special operative processing capabilities will be necessary to support analysis of raw digitalMLPA data on an average computer system. These early requirements form the base for the operative and system requirements that need to be established early in development, as they may influence all secondary choices and design specifications. Failure in compliance to such requirements may lead to the development of software that either needs users to greatly invest in computer systems, or simply leads them to search into alternative choices. When we are dealing with a wide range of different user types, we also need to consider that different users may have different availability to computers systems. It is then thus imperative to design the software to support the group of users that have the lowest operative capabilities, though scalability is also a factor.

Another point that needs to be identified early in development is the mode of delivery of the software and the required configurability. Software for digitalMLPA eventually will preferentially be able to support all MLPA products over a longer period. Since digitalMLPA products are still under development, the exact requirements for the software are still changing. We may thus for instance recognize, that internal users at MRC Holland may have specific demands and want to use the software for quality control purposes. They also want to have an easy way to adjust and update the configuration, so its content matches the actual digitalMLPA products. While digitalMLPA product developers want flexibility in the software, users in a diagnostic laboratory often prefer products, software, and its configurations to be stable. This allows them to validate a technique which may then be used as an IH-IVD or part of an IH-IVD. Adjustments in software or its configuration will often an incentive for them to reperform the validation, completely or partially.

MRC Holland's internal users, who are primarily focused on researching digitalMLPA product development, can be considered as RUO users. Their preferred output should support adaptation, filtering, and manipulation, enabling comparison of results over longer periods. Unlike field users who value stable products and changing samples, Internal users anticipate that the digitalMLPA products will change while the samples remain relatively constant. RUO users typically handle larger sample groups simultaneously and require a data presentation format conducive to integrative review. On the other hand, prospective users in the diagnostic field concentrate on individual patients and prioritize extensive quality control. Eventually, diagnostic field users may prefer CE-IVD products and software due to the added burden on clinicians when using RUO products in an IH-IVD setting. To develop software that caters to all user groups, specific requirements from regulatory affairs must also be considered. For example, traceability of patient reports may be necessary in a diagnostic setting, while results should remain unalterable to ensure data integrity. Addressing these contrasting demands calls for a flexible framework with extensive configurability, along with modes that manage risks by limiting adaptability for diagnostic-focused users.

We may furthermore need to recognize that the success of the evaluation of RUO product by users influences the progressive move of those products into IH-IVDs, which may then stimulate the production of CE-IVD products. The transfer of research into diagnostics is also more likely to occur within institutions as a consequence of trust rather than availability alone. Within diagnostics we may also have different groups of target users. A small institute for instance, is not expected to have much automatization and is more likely to be interested in software that can be operated using a Graphical User Interface (GUI). A single user of a digitalMLPA kit will likely execute the MLPA procedure as well as analysis of the data. A large service lab on the other hand that performs hundreds of analyzes each day will probably have a specialized department for the analysis of data and automated pipelines that revolve around Laboratory Information Management System (LIMS). This type of user is unlikely to be interested in GUI applications and will rather integrate a technique and related software components into their existing pipelines. To be able to support these kinds of features specialized software architectures are necessary. Early in development, conceptual, logical, and physical data models need to be created in a sequential process that involves all members of the data management team and business users. Agreement on what is needed is essential to establish, otherwise, the data models may not fully capture the business context of data or meet an organization's information needs. Conceptual modeling may thus be an important part to get to a point of understanding of what is needed before building commences. Knowledge and understanding of a complex usage environment may result to the process of creating a more usable and useful tool. Another important part that needs to be considered early in development is the method of documentation, which may be the results of the risk classification, but proper documentation may also lead to transparency regarding evidence about its performance and algorithms. Choosing a fitting strategy early in development may make the development of software easier, as well as testing and integration.

#### **3.6 Iterative behavior**

To ensure a comprehensive and effective approach to software development, it is crucial to recognize and adapt to the varying needs of different elements throughout the development process. As depicted in **Figure 1**, attention to these elements should be iterative and correspond to specific stages of development.

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

**Figure 1.** *Elements that are expected to return on a cyclical basis.*

By making well-considered decisions and obtaining team agreement on goals and timelines, significant time can be saved, and disappointment and frustration can be avoided.

It is important to acknowledge that these elements are interconnected and that the software's scope may evolve over time as more information becomes available about the goals. Therefore, making decisive choices regarding the prioritization of development components and understanding their mutual influences will significantly impact factors such as cost, agility, simplicity, scalability, fault tolerance, performance, and extensibility. In this context, the creation of data models and workbenches assumes a crucial role in the development process. They provide valuable insights into the possibilities and often inspire early users to envision software implementation approaches. Consequently, these investigations may lead to the identification of new requirements that will influence the establishment of the software architecture. Overall, by recognizing the dynamic nature of software development, adapting to changing requirements, and leveraging tools such as data models and workbenches, developers can ensure a more informed and effective development process.

#### **3.7 Software architecture**

The architecture style chosen for an application plays a crucial role in determining its characteristics and behavior. Certain styles are particularly well-suited for highly scalable systems, which are often necessary for accommodating a large volume of users, as seen in service labs. On the other hand, some architecture styles enable developers to respond quickly to changes in requirements. Each style possesses its own strengths and weaknesses, and selecting the appropriate one that aligns with specific business needs and goals will greatly impact the subsequent stages of application development, as well as its extensibility and usability. Prior to embarking on significant software

projects, companies or institutes intending to develop software may find it beneficial to initiate modeling projects. During this phase, data modelers or architects interview stakeholders to gather comprehensive requirements about the processes involved. Business analysts may also contribute to designing conceptual and logical models, which can subsequently be employed to convey technical requirements to designers. Skipping these crucial steps can result in implemented software architectures and data models that fail to fully capture the organization's and users' needs. In recent years, the field of software architecture has witnessed significant advancements, leading to the emergence of new styles such as microservices and domain-driven design. Architecture styles provide an overview of the system's macro structure, while patterns offer structural building blocks that can be utilized within architecture styles to address specific problems. Well-designed patterns have the potential for reuse in applications and company infrastructure. This section aims to explore various considerations in architectural styles during the early stages of software development for digitalMLPA, with the objective of meeting project business needs. The choices made in architectural styles have far-reaching consequences, impacting the overall development process, including quality assurance and the pathway to certification.
