1.
Introduction
In today's rapidly evolving landscape of digital healthcare, we are witnessing significant advancements in software designed to function independently as medical devices. These Software as a Medical Device (SaMD) solutions have the capacity to treat, diagnose, monitor, alleviate symptoms, prevent diseases, and track infection progression. The increasing demand for remote patient monitoring, telemedicine, and technological progress is propelling the adoption of SaMD. SaMD, as defined by the IMDRF (International Medical Device Regulators Forum), refers to software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device. Its versatility spans various medical applications, including diagnosis, therapy, monitoring, and disease prevention, and can be deployed across multiple platforms such as computers, mobile phones, and standalone devices.
During the COVID-19 pandemic, SaMD played a crucial role in remote patient oversight, providing reliable insights into medical conditions and guiding treatment strategies while prioritizing safety and prevention. This global health crisis accelerated the adoption of digital health innovations like SaMD, as healthcare providers and patients sought alternative avenues for delivering and accessing medical care. The market for SaMD was valued at USD 1443.69 million in 2022, with a projected Compound Annual Growth Rate (CAGR) of 40.1%, reaching USD 10913.4 million by 2028. SaMD is revolutionizing the healthcare industry by leveraging software to enhance patient care, improve accessibility, and drive innovation.
However, alongside these revolutionary advancements in SaMD come challenges regarding safety, reliability, regulatory compliance, development processes, and data privacy. Regulatory bodies, tasked with ensuring healthcare effectiveness and patient safety, struggle with promoting innovation while upholding stringent standards in the SaMD landscape. Integration of modern SaMD development processes with patient safety and regulatory compliance presents a significant challenge, as regulatory agencies strive to strike a balance between fostering innovation and safeguarding public health. Large-scale organizations encounter obstacles in implementing best practices and establishing quick-feedback loops within pilot programs to address emerging challenges effectively.
2.
Regulatory Landscape
There are, in fact, a great number of regions that make up the global market for medical devices. Nevertheless, it is clear that the United States and the European Union hold the position of being the greatest marketplaces. It is worth highlighting that a SaMD product is classified as a medical device and is therefore subject to regulatory scrutiny.
Regulatory agencies worldwide have identified the need to build a consistent framework and set of standards for Software as a Medical Device, recognizing its unique qualities that go beyond those of a conventional medical device or hardware. This framework has the potential to provide a significant boost to all stakeholders, including regulators, by fostering secure innovation and ensuring the well-being of patients. Within the realm of SaMD, manufacturers conduct verification and validation testing to guarantee that their products align with the specified design inputs and user requirements. SaMD is a widely recognized term on an international level, as defined by the IMDRF. On the other hand, MDSW is a term exclusively used within the EU.
2.1 U.S.
FDA Regulations for SaMD
In the domain of healthcare technology, the FDA's approach to Software as a MedicalDevice (SaMD) is intricately shaped by the standards set forth by the International Medical Device Regulators Forum (IMDRF). This interpretation defines SaMD as software designed to fulfill medical purposes independently of hardware medical devices. To ensure the safety and efficacy of such software, the FDA has meticulously crafted frameworks for risk assessment, Quality Management Systems (QMS), and clinical evaluation methods. Manufacturers of SaMD are mandated by the FDA to adhere to the Quality System Regulation (QSR) stipulated in 21 CFR Part 820. This regulation lays down the groundwork for medical device manufacturers to establish and maintain a robust quality system, encompassing crucial aspects like design controls, risk management, and other quality measures throughout the software lifecycle.
Prior to entering the market, SaMD may require submission to the FDA, with the specific type contingent upon its risk classification. This submission process could involve a 510(k) premarket notification or Premarket Approval (PMA). To streamline this process, the FDA has provided comprehensive guidance, such as the "Content of Premarket Submissions for Software Contained in Medical Devices," which delineates the requisite documentation, including risk analysis, software description, and cybersecurity measures.
The FDA's commitment to facilitating the development and regulation of SaMD is further underscored by its publication of various guidance documents tailored specifically to this domain. For instance, "Off-The-Shelf Software Use in Medical Devices" offers guidance on documentation requirements for off-the-shelf (OTS) software components, categorized based on the level of documentation needed. These components encompass software description, risk assessment, testing, and assurances concerning development and maintenance. The rising availability of general-purpose computer hardware has prompted a growing interest in integrating off-the-shelf (OTS) software into medical devices. However, it is important to acknowledge that while OTS Software is versatile and intended for general computing tasks, it may not be appropriate for a specific specialized use in a medical device. The medical device manufacturer that uses off-the-shelf software (OTS software) generally relinquishes control over the software life cycle, while they remain responsible for ensuring the device's ongoing safety and optimal performance.
The FDA has an extensive guidance known as "Software asa Medical Device (SaMD): Clinical Evaluation" that serves as a
cornerstone, outlining principles for the clinical evaluation of SaMD. It
provides a structured approach to generating and assessing clinical evidence to
establish the safety, effectiveness, and performance of SaMD. Moreover, it
encourages global alignment of regulatory principles while allowing flexibility
in clinical evaluation methods based on the risk profile of the SaMD. The
further details on Clinical Evaluation are described in section 5. Recognizing
the importance of international standards, the FDA acknowledges various global benchmarks
applicable to SaMD, including IEC 62304 for medical device software lifecycle
processes, and guidance provided by the IMDRF specifically addressing SaMD.
These guidance documents cover a broad spectrum of topics,
ranging from device description and hazard analysis to software verification
and validation, cybersecurity, and human factors. Emphasizing the need for a
comprehensive understanding of the software's capabilities and potential
hazards, these guidelines aim to support manufacturers in creating clear and
thorough submissions for FDA review. Moreover, they serve as a roadmap for
navigating the well-defined laws and guidelines governing product approval in
the US market. Through these efforts, the FDA remains steadfast in its
commitment to fostering innovation while safeguarding patient safety and
advancing healthcare technology.
2.2 EUMDR
Regulations for SaMD
It demonstrates a striking similarity to the regulatory framework in the US, as it aligns with the established criteria that are also applied to traditional medical devices. Within the European Union's medical device landscape, specific provisions within the EU MDR govern the regulation of Software as a MedicalDevice (SaMD). While the EU MDR doesn't offer an explicit definition of SaMD, it classifies software as a type of medical device and delineates its scope in Article 2(1). According to this article, “Medical device software (MDSW) is software that is intended to be used, alone or in combination, for a purpose as specified in the definition of a “medical device” in the MDR or IVDR, regardless of whether the software is independent or driving or influencing the use of a device.” Classifying SaMD under the EU MDR entails assessing its risk level, which can range from low risk (Class I) to high risk (Class III).
Similar to
other medical devices, SaMD must adhere to the EU MDR's rigorous Quality
Management System (QMS) requirements outlined in Annex IX. The IMDRF offers
guidance on applying QMS principles tailored to SaMD development. The EU MDR
acknowledges and aligns with IMDRF guidance on SaMD clinical evaluation.
Manufacturers must furnish clinical evidence attesting to the safety,
performance, and validity of their SaMD products, commensurate with the
applicable risk class.
2.3
Software Classification in the Global Market
There exist multiple methods for categorizing medical device software, taking into account regulations in the US, Europe, IMDRF, and IEC 62304. An effective approach to determine the regulatory pathway for medical devices is by assessing the risk-based classification of the SaMD product.
A. U.S. FDA: The FDA categorizes Software as a Medical Device (SaMD) using the same risk classifications as traditional medical devices: Class I, Class II, and Class III. Recently, on April 11, 2021, the FDA issued a draft guidance document titled "Content of Premarket Submissions for Device Software Functions," replacing the previous guidance document that introduced the Level of Concern concept. The FDA intends to employ a risk-based approach to ascertain the Documentation Level of the device, which can be classified as either Basic or Enhanced. The Documentation Level serves the objective of determining the essential information required to effectively support a premarket submission that encompasses device software operations.
B. EUROPE: The risk classification of medicaldevice software is in line with that of traditional medical devices, encompassing class I, class IIa, class IIb, and class III. Nevertheless, the EUMDR offers a thorough structure for evaluating the risk classification of medical device software, commonly known as Rule 11. Annex III of the MDCG 2019-11 guidance document bridges IMDRF risk categories with corresponding risk classes under the EU MDR Rule 11. SaMD manufacturers must discern the appropriate risk class based on healthcare scenarios and the information's significance.
According to Rule 11 in Annex VIII of EU MDR, states: Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause: — death or an irreversible deterioration of a person's state of health, in which case it is in class III; or — a serious deterioration of a person's state of health or a surgical intervention, in which case it is classified as class IIb. Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as class IIb. All other software is classified as class I.
C. IMDRF: The accurate and thorough definition statement of SaMD is essential for the categorization process. The category is established through an evaluation of the information's worth in connection with healthcare decision-making, as well as the particular healthcare scenario or condition. The determination of the four categories (I, II, III, IV) is based on the level of impact on the patient or public health as shown in table 1. In these cases, accurate information provided by the SaMD is essential for effective treatment, diagnosis, clinical management, and prevention of severe health outcomes, including death, long-term disability, or other significant health deterioration. This, in turn, helps to minimize the overall risk to public health. The categories are prioritized based on their respective significance in relation to each other. Category IV displays the highest amount of impact, while Category I shows the lowest level of influence.
Table
1: SaMD Categories according to IMDRF
D. IEC 62304: As per IEC 62304, the software is classified based on the safety classification. The purpose of the safety classification is thus to classify the software lifecycle management in accordance with the potential risk to the patient in case of any software failure or anomaly. Consequently, this classification has a substantial impact on the capacity to monitor and oversee records, offering a way to showcase proficient risk management across the entire medical device development procedure. In order to prevent injury to the operator, patient, or other individuals in the event of a hazardous situation to which the software system may contribute in the worst-case scenario, the manufacturer is required to assign a software safety class (A, B, or C) to each software system as indicated in below Fig 1.
Fig 1: Software Safety Classification according to IEC 62304
Class A
signifies the lowest level of relevance, whereas class C suggests the highest
level of significance. It's crucial to note that until a
software safety class is assigned to each software system, Class C requirements
will be enforced. Considering
its critical nature, the integration of medical device software necessitates a
meticulous & comprehensive lifecycle. The classification scheme for
software safety is as follows:
Class A:
There is no possibility of danger or harm to health.
Class B:
There is a possibility of non-serious injury.
Class C: There is a possibility of death or serious injury.
3. Software Development Life Cycle
Process
For a
medical device software manufacturer, it is crucial to demonstrate the
conformity of your software with the current standards, namely the "IEC62304 - medical device software - software life cycle processes" standard.
This standard is applicable if the software functions as a medical device on
its own or if the software is an integral component of a medical device. This
standard offers a structured set of life cycle procedures that include specific
activities and tasks required for the secure design and upkeep of software usedin medical devices. This standard specifies the necessary criteria for each
life cycle step. The software
development process comprehensively outlines the necessary phases, starting
with the initial planning stage and extending all the way to the final
verification and validation procedures. This guarantees that all software is
developed and evaluated to adhere to the most stringent quality criteria.
The Clause 5 of the IEC 62304 standard specifically addresses the software development process, which comprises eight subclauses and Thus ensures that all software is designed and tested to meet the highest quality standards. The eight subclauses outline requirements starting from the initial planning phase through to the concluding verification and validation procedures. The software development plan comprehensively outlines the activities, tasks, and responsibilities involved in the software development process, as well as the sequential and interconnected nature of these operations. The Software Requirements Analysis section underscores the critical need for manufacturers to maintain comprehensive documentation of software requirements, encompassing both functional and non-functional aspects. This documentation serves as a crucial guide throughout the software design process and ensures continuous maintenance and adherence to specifications. The Software Architectural Design clause establishes the overarching framework and arrangement of the software, encompassing modules, interfaces, and data flows, with the aim of meeting the specified requirements effectively. The Software Detailed Design section emphasizes the importance of developing a comprehensive design based on the software architecture. The Software Unit Implementation and Verification process ensures that software units are successfully implemented and thoroughly verified in accordance with their design. The clause on software integration and integration testing underscores the critical need to combine individual software units into a unified system and thoroughly test the interactions between different components. This process ensures the seamless integration of software modules and validates the system's end-to-end functionality through comprehensive testing. The Software System Testing encompasses the comprehensive testing of the program at the system level. It is advisable for manufacturers to conduct comprehensive testing of the entire software system inside its operational environment to ensure that it aligns with the specified software requirements. The Software Release clause outlines the conclusive stage of the software development process. The manufacturer must provide conclusive evidence demonstrating that the software has successfully met all requirements and is fully prepared for its intended usage.
The requirements included in IEC 62304's Clause 5 are analyzed in figure 2, showing how they relate to various safety classes. According to experts, the IEC 62304standard can significantly streamline the process of acquiring regulatory approval. Moreover, the recognition of these guidelines by the FDA underscores their broad importance at a global scale.
 |
Fig 2:
Analysis of Software Requirements for various classes. |
The Med Tech Companies should prioritize the reporting and efficient management of Software of Unknown Provenance (SOUP) as it lies beyond the jurisdiction of the software manufacturer. SOUP generally refers to software components that have been developed and are readily available, but have not been specifically designed for integration into medical devices. As a result, there is a possibility that it could have a detrimental effect on both the product and the infrastructure of the regulated application in which it is being developed. Factors like reliability, cyber threats, and other dangers may have the potential to adversely affect safety. Medical software producers have received multiple guidelines highlighting the importance of implementing proper procedures, such as risk assessment and validation, in order to ensure the security of the software, especially when using SOUP, including third-party software.
4. Risk Management in Software
Development
Medical device regulations worldwide have two important components. Firstly, manufacturers are obligated to establish procedures that guarantee the safety and efficacy of medical devices, including Software as a Medical Device (SaMD). Secondly, they must ensure that the software performs its intended function without posing any unacceptable risks of harm. An important lesson given by the regulations is that software cannot be made safe by testing alone. Software, while not inherently harmful, has the potential to contribute to hazardous conditions that may result in direct or indirect harm. Manufacturers must take into account software from a holistic viewpoint. The IEC 62304 standard closely aligns with ISO 14971. This alignment ensures that potential hazards related to software are systematically identified and mitigated through a structured approach. IEC 62304 mandates the inclusion of software risk management as a crucial component for both the software development process and the overall device risk management process. Manufacturers ought to concentrate their efforts on the following key areas:
- Examining software systems, their components, and their correlation with potential device risks.
- Identifying potential software causes that could lead to hazardous situations.
- Examining and determining efficient risk mitigation strategies
- Assessing the adoption of risk control methods
- Assessing the efficacy of risk mitigation strategies, both pre and post-release
An obstacle in evaluating software risk lies in the complexity of estimating the likelihood of software malfunctions that may lead to dangerous circumstances, particularly for manufacturers lacking extensive field performance data to inform their assumptions and calculations. The task at hand involves assessing the extent of damage, given that the damage is not directly caused. The prevalent risks associated with diagnostic software involve the occurrence of inaccurate or delayed diagnostic outcomes. It is important to take into account any inaccurate information that may be included with the diagnostic result.
5. Software Validation and Clinical Evaluation
Validation plays a vital role in guaranteeing the safety and effectiveness of medical device software. Software validation plays a critical role in ensuring that the software meets user needs and intended uses, ultimately safeguarding patient safety and product efficacy. Software validation is a systematic process that involves examination and objective evidence to confirm that the software specifications conform to user requirements and intended applications. The validation process encompasses several key activities, each designed to establish confidence in the SaMDs safety and effectiveness. One crucial step is risk analysis, which identifies potential hazards and provides mitigations to address them. Requirements traceability is another essential component, linking requirements to design, development, and testing phases, ensuring a clear trail of evidence. Design reviews and code inspections are conducted to scrutinize the software's architecture and implementation, respectively. Furthermore, validation testing is performed, including evaluating functional requirements, usability testing (assessing user experience), performance testing (evaluating system performance under various conditions), and security testing (identifying and mitigating vulnerabilities). Software validation has the potential to save long-term expenses by simplifying and reducing the cost of making reliable modifications to software and revalidating software alterations. Software maintenance has the potential to account for a significant portion of the overall cost of software across its full life cycle. Implementing a well-developed and thorough software validation process can significantly decrease the overall expenses associated with software development. This is achieved by lowering the validation costs for each succeeding product release. It is highly recommended that sponsors incorporate comprehensive documentation of test plans and test results into the verification and validation process for the off-the-shelf (OTS) software. This will ensure a thorough and rigorous assessment of the product's functionality and performance. Testing activities encompass not only the responsibilities of the OTS software developer, but also the obligations of the sponsor in assessing the suitability of the OTS software for its application in the designated medical device.
The term "Clinical evaluation of a SaMD" refers to
a series of continuous actions carried out to evaluate and analyze the clinical
safety, effectiveness, and performance of a SaMD, as specified by the
manufacturer in the SaMD's defining statement. A Software as a Medical Device
(SaMD) can be defined as a sophisticated program that employs an algorithm,
logic, set of rules, or model to process digitized content as input and provide
an output with specific medical applications, as determined by the SaMD
manufacturer (Fig 3) . The risks and benefits associated with SaMD outputs
mostly come from the potential of inaccurate output, which can have an impact
on the clinical care of a patient.
Fig 3: SaMD Basic Programming Model
Clinicalevaluation is a systematic and planned process to continuously generate, collect, analyze, and assess the clinical data pertaining to a SaMD in order to generate clinical evidence verifying the clinical association and the performance metrics of a SaMD when used as intended by the manufacturer. The role of the SaMD in achieving a clinical condition determines the quality and scope of the clinical evaluation. This role also makes sure that the SaMD's output is clinically valid and can be used in a reliable and predictable way. This part guides SaMD manufacturers through the process of gathering evidence for the clinical evaluation of a SaMD. It does this by using simple steps and providing links to techniques, definitions, and sources that may assist a SaMD manufacturer collect appropriate information.
The level of clinical evidence required for software as a medical device (SaMD) depends on factors such as the maturity of the underlying clinical association and the confidence in applying it to the specific SaMD. Manufacturers must establish a comprehensive Clinical Evaluation Plan (CEP) to define the criteria for generating clinical evidence.
The CEP should identify relevant data sources, analyze their
relevance to demonstrating conformity with
General Safety and Performance Requirements, and document the assessment and
derived clinical evidence in a Clinical Evaluation Report. Both the FDA and EUMDR emphasize the importance of generating robust clinical evidence through
three key elements:
1.
Valid clinical association:
Establishing a well-founded relationship between the SaMD's outputs and a
clinical condition or therapeutic area.
2.
Analytical validation: Verifying
that the SaMD accurately processes the input data to generate appropriate
outputs.
3. Clinical validation: Confirming that the SaMD's outputs
achieve the intended clinical purpose in the target population.
The clinical evaluation process is iterative and must be updated throughout the SaMD's lifecycle as new data is obtained. Comprehensive clinical evidence, covering all three elements, is crucial to ensure the safety and effectiveness of SaMDs before market authorization and during post-market surveillance.
Fig 4: Clinical Evaluation Elements
6.
Ethics and Privacy Consideration
The expanding incorporation of wireless, Internet- and network-linked functionalities, along with portable media such as USB or CD, and the frequent electronic transmission of health information and other data related to medical devices, underscores the growing importance of strong cybersecurity measures in guaranteeing the safety and efficacy of these devices.
In addition, there has been an increase in the frequency and intensity of cybersecurity assaults specifically aimed at the healthcare industry, resulting in a heightened risk of clinical implications. Regrettably, the performance of medical devices and hospital networks has been affected by cybersecurity events, leading to disruptions in patient care delivery in healthcare institutions. These cyber attacks and exploits possess the capacity to inflict harm upon patients as a result of clinical hazards, including potential delays in diagnosis and/or treatment. Presently, the FDA regulates AI applications involved in clinical decision-making, whether in diagnosis or therapy, as Software as a Medical Device (SaMD). Nevertheless, there are still obstacles that need to be addressed in order to establish more targeted rules. These challenges include the inherent complexity of AI/ML, the potential risks associated with cybersecurity, and the fast-paced advancement of these technologies.
The utilization of AI-based SaMDs and digital twins holds immense promise to revolutionize healthcare delivery for the better. However, as emphasized earlier, significant ethical problems arise about the regulation of these algorithms. The five key elements of biological ethics, namely utility, patient autonomy, distributive justice, non-malfeasance,, and beneficence, can be analogously correlated with the regulatory concerns surrounding AI/ML. These concerns encompass informed consent, algorithm fairness and biases, intellectual property legislation, data privacy, and safety and transparency as shown in fig 5.
Fig 5:
Similarities between biological ethics and the ethics of AI/ML, digital twins,
and SaMDs
Ensuring
compliance with the GDPR (General Data Protection Regulation) and the HIPAA
(Health Insurance Portability and Accountability Act) is fundamental for maintaining
ethical and privacy considerations for SaMD. These regulations govern the use,
disclosure, and protection of personal and health information.
Firstly, both GDPR and HIPAA mandate obtaining explicit
consent from individuals before processing their personal or health data.
HIPAA's Privacy Rule requires covered entities to obtain patient authorization
for the use and disclosure of PHI (Protected Health Information), while GDPR
mandates organizations to obtain explicit consent for processing personal data.
Secondly, these regulations establish strict guidelines for
data ownership, privacy, and security. HIPAA sets rules for protecting PHI,
including requirements for de-identification and restrictions on data use and
disclosure. GDPR sets stringent guidelines for handling personal data, such as
data minimization, storage limitation, and security measures.
Thirdly, transparency and traceability are critical aspects
addressed by these regulations. HIPAA requires covered entities to provide
patients with access to their PHI and an accounting of disclosures, while GDPR
grants individuals the right to access their personal data, receive information
about its processing, and have it corrected or deleted.
Furthermore,
both GDPR and HIPAA mandate organizations to implement appropriate technical
and organizational measures to protect the security, confidentiality of
personal and health data, including robust cybersecurity measures.[18] SaMD
manufacturers must adhere to these regulations to avoid potential legal and
financial consequences arising from ethical or privacy-related violations.
Failure to comply can result in hefty penalties and reputational damage. By
proactively maintaining compliance with GDPR and HIPAA, SaMD manufacturers can
ensure the ethical and secure handling of sensitive personal and health data,
fostering trust and credibility among patients and healthcare providers.
7. Future Trends
SaMD represents a noteworthy advancement in the realm of digital transformation within the healthcare sector. Furthermore, this stage is bolstered by a multitude of trends that must be adhered to –
Internet of Medical Things (IoMT): It serves as a key facilitator in efficiently and effectively managing the data gathered by SaMD devices. It enables the exchange of healthcare data in a manner that is advantageous for making prompt decisions for both patients and doctors. In the present era, it is evident that SaMD developers are increasingly forming relationships with IoMT systems to facilitate meaningful data sharing.
Miniaturization of Medical Device: The current trend toward reduction in medical devices offers a number of benefits, including enhanced patient comfort, portability, and procedures that are minimally invasive. Surgeons, diagnosticians, and medical professionals are all being revolutionized by miniature devices that are coupled with superior robotics and artificial intelligence, which is leading to improved patient outcomes.
Telehealth or Telemedicine: The advent of the pandemic has brought about a transformative evolution in telemedicine, making it more accessible and effective for users. This trend has significantly enhanced the application of SaMD, as it has the capability to collect vital signs of patients even from a distant place. This would additionally enhance the demand for medical technologies that promote remote monitoring, such as the development of EHR (Electronic Health Record) and EMR (Electronic Medical Record) software.
Furthermore, it is essential to keep up with the latest trends in SaMD, such as AI and Robotics, Personalized Medicine, Home Diagnostics/ Diagnostics Consumerization, AR/VR, and similar advancements.
8. Conclusion
SaMDs
are revolutionizing healthcare delivery by offering innovative solutions for
diagnosis, treatment, and monitoring. However, as regulatory bodies adapt to
this digital era, SaMD developers must navigate complex regulatory landscapes
effectively. Compliance challenges, such as data privacy concerns and risk management, must be addressed proactively to mitigate potential risks and
ensure patient safety. The SaMD development life cycle requires meticulous
attention to software design, validation, and verification. Best practices in
risk management, clinical validation, ethical considerations, and data privacy
strategies play pivotal roles in SaMD development and adoption. Artificial
intelligence and machine learning are transforming the healthcare sector, and
risk-based validation is crucial for assuring optimal product performance
without burdening manufacturers. By using an appropriate software development
methodology, organizations that produce
SaMD may guarantee the precise performance of their products and enable
continuous improvement through the utilization of additional data. The
integration of advanced technologies like AI and ML into SaMDs underscores the
potential for significant medical advancements, albeit accompanied by complex
regulatory and ethical challenges. Therefore, while SaMDs represent a
significant innovation in healthcare technology, careful management through
their development life cycle is necessary to address inherent risks and
maximize their potential benefits.
D.O.I.: https://www.researchgate.net/publication/380069279_Navigating_the_Regulatory_Landscape_of_Software_as_a_Medical_Device_SaMD_Compliance_Challenges_Best_Practices_and_Future_Trends
Author.: Akash Kirani