SaMD Audit Support | How to Address the Challenges SaMD?
Article Context:
- Software as a Medical Device (SaMD)
- How does US FDA Regulate the Medical Devices?
- SaMD Audit
- SaMD (vs) SiMD
Modern technology is always crucial to the advancement of the healthcare sector and the quality of healthcare provided to patients. Technology enables medicine to change, adapt, and advance, from the centuries-old discovery of tools like the magnifying glass and the stethoscope to more recent innovations like the CT scanner and the MRI.
Scientists, researchers, doctors, and computer programmers are collaborating to develop innovative technologies that transform healthcare. Professionals who use them can help patients to maintain better overall health and save their lives. Thanks to the modernization! Some of the most significant technological advancements in the field of medicine take the shape of software.
The Role of Software as a Medical Device (SaMD)
At any contemporary healthcare facility, it is easy to see how prevalent technology is. Medical personnel may perform their respective tasks promptly and accurately using a wide range of software-enabled equipment, from prognosis or diagnosis to patient monitoring and treatment administration. Hence, a medical device's software (SiMD) is just as important as the actual medical equipment. Software as a medical device refers to software solutions that do not live in a medical device but are nonetheless used for medical purposes (SaMD). It should come as no surprise that both technological marvels are subject to the strict regulatory standards that apply to medical equipment.
The medical device laws of the nation where they are used apply to both SiMD and SaMD. For instance, the Health Science Authority (HSA) in Singapore, the European Commission in Europe, and the Food and Drug Administration (FDA) in the United States. Every nation has a regulatory standard for SaMD; however, such standards vary depending on the nation's internal dynamics and healthcare philosophy. Therefore IEC 62304:2006, an international regulatory standard that is recognised in many nations, is a required compliance for SaMD providers.
How does US FDA Regulate the Medical Devices?
When it comes to the detail of regulatory guidelines relative to medical device software, the FDA is years ahead of other regulators, including those in Europe. For more than 20 years, the FDA has been releasing software guideline documents, but the previous three to five years have seen a particularly high volume. To their credit, FDA is making a determined effort to ensure that its regulatory framework does not inhibit innovation and is aware of the significance (and pervasiveness) of software in all kinds of devices. New or updated guidelines have been released recently covering a wide range of topics.
On topics including life-cycle management, interoperability, and medical device cybersecurity, several international standards delve even deeper. International standard bodies, European agencies, and the FDA have all released a wide range of advice documents about medical device software.
What are the Audit Challenges of SaMD?
Medical devices are increasingly taking the shape of pure software due to the rapid growth of medical digitalization. These devices now perform clinical evaluation, diagnosis, surgical planning, and even navigation during surgery and post-operative care. In medical devices that combine hardware and software, software often controls the hardware's primary tasks (i.e., firmware). The use of software to improve connection and the sharing of medical data across platforms for information technology and medical devices has, however, gradually increased with the industry's gradual adoption of information and communication technology.
The management of technical documents
While software such as medical devices (SaMD) has a quick development cycle, integrating software components one at a time will require several iterations. Two significant regulatory requirements, nevertheless, will raise the cost of implementation or make compliance challenging. The first is that every design change must be managed under design control, which may limit the amount of flexibility in software development. When it comes to this matter, we typically talk with the development team about how much change needs to be controlled. The second is that risk management typically conducts risk assessment when there is a more complete concept (or requirement specification), and then considers the high-risk part during development.
Automated tools
Throughout the software development process, there is an automated software that gives programmers access to automatic testing, version control, or even electronic quality management systems (eQMS). The two difficulties listed below will be encountered during the delivery process: The first problem is deciding what data the development team should gather. The content that must be included in the quality management system or the delivery document is typically discussed with the team and filtered. The quality team and the development team must agree on two things: (1) the level of involvement that the development team should anticipate from documentation efforts, and (2) the precise working arrangement between the two teams. The second difficulty is determining how to assess the performance and compliance of these automated technologies.
Release and deployment of software
Software deployment and release rules have standards that are comparable to those for ordinary medical equipment, which must have inspection reports attached before they leave the factory. The software includes records of unresolved anomalies, designs, test verification reports, deployment plans, review documents, approval records for releases, etc. The concept of Continuous Integration/Continuous deployment (CI/CD), which lowers human errors and increase the quality of software services, has led to the widespread usage of automated solutions. Version control, software development, and deployment are some of its automated processes. We will also talk about how to gather and arrange the necessary data into a compliance record with the development and operations staff (DevOps).
Verification and certification of the software
The goal of the automated tools' verification and validation is to make sure that the software can perform the necessary functions and will not expose users to additional hazards. Software functions and tools are evolving every day. The requirements call for non-product software employed in the development process, such as the automation tools, electronic quality management system (eQMS), and even goods, in addition to the software of the medical product itself. Initially created for a variety of uses, the software used in the verification and manufacturing phases may not entirely adhere to the standards governing medical devices. The functions that could have an impact on the quality of the product or the quality systems must thus be validated.
Planning for clinical validation
Like traditional medical equipment, software or medical devices undergo performance testing, with varying difficulties based on the degree of risk. Yet, during the design stage of clinical trials, the software frequently encounters the following situations, which could have an impact on the cost of the trial as well as the safety and efficacy of the evaluation.
Cybersecurity
To implement features that have been widely used in the market, such as data chart generation, graphical user interface (GUI), database management system, or machine learning library, software developers frequently look for some commercial/licensed existing software or technologies which are collectively referred to as OTS (off-the-shelf software) or SOUP (software of unknown provenance). It is typically challenging for manufacturers to confirm and inform users (doctors, carers, patients, etc.) of the affected medical devices and how to reduce the impact of the vulnerability. This is especially true when there are information security vulnerabilities in products or existing softwares.
What are the differences between SiMD and SaMD?
The development of software-based products with no connection to hardware devices whatsoever has only recently started in the medical device sector. While not only typical medical devices, but also software as a medical device (SaMD) has the same potential to enhance patients' quality of life worldwide.
Regulating agencies all around the world continue to classify them as medical devices. I want to debunk some of the myths surrounding these devices in this tutorial, as well as provide you with information on how they are governed and what to expect if you decide to create one.
| SiMD | SaMD |
|---|---|
| Although SiMD and SaMD are sometimes mistaken, most of it is self-explanatory. SiMD is the programme in question if it aids in the operation of a medical device in any way. Naturally, SiMD refers to software that controls a medical device's operations or analyses entire data the device generates. SiMD is the software used for remote device control. | IMDRF [International Medical Device Regulators Forum] defined SaMD [Software as a Medical Device] as software intended to be used for one or more medical purposes without being part of a hardware medical device. (Source: FDA) |
| It can be confusing because, in addition to performing these tasks, many additional software applications that are classified as SiMD also have some traits with SaMD. For instance, SaMD frequently requires internet or wireless connectivity. Nonetheless, it is regarded as SiMD if software aids in establishing such connectivity via Wi-Fi or Bluetooth. | Software must be independent of already-in-use medical devices to be considered as an SaMD. Any software that runs or assists in running equipment like an MRI, EKG, EHR, X-ray, insulin pump, or any other number of devices falls under the category of SiMD, not SaMD. Using non-medical devices like laptops, cellphones, tablets, smartwatches, or other computing platforms, SaMD is operated. |
| A mobile app, which is virtually always connected to SaMD, can occasionally be SiMD. The FDA provides a more detailed explanation of which mobile applications are not considered medical devices, but the main concept is as follows. With some medical devices, a mobile app powered by medical software could be the main means to read or examine the results that the equipment generates. The word "primary" is important here. The medical equipment qualifies as SiMD because you cannot operate it without this software. | Although SaMD does not deal with how medical devices function, they frequently collaborate with them. SaMD can monitor ECG and notify doctors when something is wrong, analyse images from an MRI or X-ray to check for problems, and build a treatment plan that is carried out by an insulin pump to assist people to control their diabetes. SaMD and SiMD are sometimes mistaken since they frequently collaborate with medical devices. |
Knowing more about SaMD and SiMD should help you understand how the two differ from one another. But some of this may still seem exceedingly perplexing and complicated at this point. In these situations, asking two straightforward questions will help you distinguish between the two most effectively. Those are, Is this software a standalone medical device? Or is this software a component of other medical apparatus? You can always compare SaMD and SiMD by responding to these.
Conclusion
Software for the medical sector comes in various forms and understanding the differences between these sorts of software is essential to understanding what this fantastic software is doing for medicine. Software as a medical device (SaMD) and Software in a medical device (SiMD) are the two main types of medical softwares reshaping the medical sector. To assist you in better comprehending both the categories, we compared two types of software here and provided examples of each category.
FAQ's
What is SaMD in the medical device?
A medical software solution known as Software as a Medical Device (SaMD) can conduct one or more medical tasks without the use of a physical device. SaMD applications are often employed using non-medical gear connected to virtual networks with the goal of treating or preventing diseases.
What is a MDSAP audit?
The MDSAP (Medical Device Single Audit Program) is a global initiative that change the way how regulators approach, audit, and monitor the manufacturing of medical devices. It also enables a single regulatory audit of medical device manufacturer’s QMS that satisfy the standards of numerous regulatory jurisdictions.
Is EHR a SaMD?
Software with a medical purpose running on a general-purpose computing platform (one without a medical purpose) is another illustration of SaMD. Specifically, software designed for diagnostics using a consumer digital camera’s tri-axial accelerometer.
What class is SaMD?
FDA classifies SaMD using some risk classes as it does for all the traditional medical devices i.e., Class I, Class II, and Class III. Just to reiterate, although you will have to choose a “level of concern” for your pre-market submission to the FDA, this does not determine your risk class.