The 5 Most Common Mistakes in Designing Wearable Devices for Healthcare
Remote patient care using wearable technology is now a normal part of healthcare in many...
No other sector is benefiting more from our current tech revolution than healthcare. Innovations in the worlds of IoT and wearables are creating a world of possibilities for consumer electronics. Meanwhile, hospitals are harnessing technology for everything from diagnostics to life-saving implants.
According to the World Health Organization,more than two million different kinds of medical devices are helping people worldwide. At the heart of most modern devices is software. Computer software plays a vital role in facilitating standard operations, handling data, making sense of crucial medical information, and more.
With our dependence on software growing, questions about regulation are at the forefront. So, when is a piece of software classified as a medical device? The answer to that question isn't just a matter of marketing. It's about determining the appropriate regulatory work needed to keep patients safe and to get your device through FDA or CE approval.
Ultimately, the goal of medical device regulation is to minimize the risks for patients. Guidance from governing boards like the FDA and CE ensures that devices are safe. Risk analysis is required, and significant risks must be mitigated. Official regulation measures also help identify and monitor any adverse effects that might arise.
Compliance is not an option. If you start marketing a medical device without approval, you risk having the FDA or CE order you to stop selling the product. So, when is software a medical device?
Software is a recent but major concern for the FDA because it's a significant source of patient injury. One study by a medical products agency in Sweden found that software issues were the root cause for many of the top ten patient incidents in healthcare. Several other reports found that electronic record-keeping and software-related problems increased patient risks. Many avoidable instances of mistreatment and misdiagnosis were a direct result of faulty software.
As software became more capable of handling essential healthcare tasks, the need for more regulation grew.
Eventually, different standards for software development came to be. These guidelines are just as stringent and detailed as the requirements for physical devices, but they're unique to the software lifecycle and its specific applications.
Understanding whether a piece of software classifies as a medical device is paramount. Software that meets the standards requires registration and strict compliance. Regulatory measures can impact the development process and may require a shift in core features. Failure to follow safety standards could result in enforcement actions, such as fines, injunctions, and even criminal prosecution.
The liability risks are far too significant to ignore, which is why getting help from a software and firmware developer like Voler Systems can make all the difference.
Software is everywhere in the healthcare industry. Healthcare providers utilize it across various applications and platforms, including communication, data storage, and more. Typically, software falls into one of four primary subclasses. These include:
Subclasses 1 through 3 are the focus of regulation. Here we will focus on subclass 1 and 2, although most of what is written here applies to subclass 3.
It is important to note that software is classified as a medical device based on the claims made in its marketing, and marketing includes any description of the software, whether it is on the packaging, on your website, in social media, or in any communication with doctors and patients. Classification as a medical device is not straightforward, and it is best to get advice from regulatory experts. Voler can refer you to them.
The technical definition of SaMD comes from the International Medical Device Regulators Forum (IMDRF), an organization in which the United States is an active member. It's the exact definition that the FDA uses. The IMDRF states that a SaMD is:
"Software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device."
To put it simply, it's software that functions independently of a physical device. It's possible to embed the software into hardware, as is often the case with modern medical devices. It can also work on general-purpose platforms or interface with other hardware. However, the SaMD is a standalone piece of the healthcare puzzle that isn't integral to hardware function. Typically, such software runs on a computer, a smartphone, or a smartwatch which is not a medical device.
Some good examples include programs that offer:
SaMD software may perform its core function on any computing platform to classify as a medical device. It does not drive or control other hardware as part of a closed-loop system.
When the software is part of a device, the whole device, including the software, may then be a medical device. The FDA defines a medical device as follows:
(h)(1) The term ‘‘device’’ means an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including any component, part, or accessory, which is—
(A) recognized in the official National Formulary, or the United States Pharmacopeia, or any supplement to them,
(B) intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or
(C) intended to affect the structure or any function of the body of man or other animals, and
which does not achieve its primary intended purposes through chemical action within or on the body of man or other animals and
which is not dependent upon being metabolized for the achievement of its primary intended purposes. The term ‘‘device’’ does not include software functions excluded as follows
Software used for administrative support of a healthcare facility.
Software for maintaining or encouraging a healthy lifestyle and is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease.
Software to serve as electronic patient records.
Software for transferring, storing, converting formats, or displaying clinical laboratory test or other device data and results.
If you are not making drugs, the key part from above is that a device is a medical device if it is intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, or it is intended to affect the structure or any function of the body of man or other animals.
The software is part of the device and must be handled as a medical device.
The next question is: what is classified as software? There are additional requirements when a medical device is or contains software, so it’s desirable to avoid having software, if possible.
Treat these as software
A processor with software running on it
A large gate array with a processor core running code
Treat these as not software
Digital hardware such as a programmable logic device (PLD)
Hardware with a software interface such as an I2C or SPI interface
A large gate array without a processor core
The FDA puts medical devices into three main classes based on a risk assessment. The classes represent the potential dangers software can present to patients.
Class I – This group has the least regulatory control. Any software or hardware in this category will have the lowest potential for harm. For some perspective, other items in this class include bandages, hospital beds, and electric toothbrushes. Class I devices can be marketed after notifying the FDA, but you don’t need to wait for FDA approval.
Class II - There are two subclasses here, and the main difference between them is how long potential risks can last. Any short-term invasive issues belong in class IIa, while long-term risks fall into category IIb.
Both subclasses include software that has the potential to cause harm if misused. Typically, these devices require post-market surveillance, mandatory performance standards, and other safety measures. The design must be done using design controls, and you must get FDA or CE approval before marketing them.
Class III - This type of software comes with the strictest regulations. In most cases, it includes software and devices that sustain human life, making its safety and efficacy crucial. Similar items that fall into this category include pacemakers, joint replacements, and artificial heart valves. The design of these devices must be done using the same type of design controls as class II devices, and you must get FDA or CE approval before marketing them. The risk analysis and regulatory review are stricter than with class II devices.
Beyond the standard class system, the FDA evaluates software as a medical device based on its scope. The clinical evaluation puts the software into one of four categories. As the category number rises, the software's impact on patients does too.
Type I – This type includes informative programs that deal with non-serious data. For example, the software might collect, store, and transmit patient data such as blood pressure readings and heart rate statistics. This type of information is regulated by HIPAA but can be used to develop treatments plans through virtual doctor visits and be transmitted to all members of a patient’s care team.
Type II - The software informs and drives more pressing matters. This type of SaMD often analyzes heart rates, predicts the risk of disease, or recommends diagnosis.
Type III – The SaMD is more active and can drive critical processes and treat severe conditions. The software might detect breathing irregularities, track skin lesions, or monitor for disease.
Type IV – This SaMD type can treat or diagnose critical issues. For example, the software may provide treatment solutions for stroke victims, reveal growth patterns for skin lesions, or screen for dangerous pathogens.
If you have software that is a medical device or is part of a medical device, you need to meet extra requirements, most of which is described in IEC/ISO 62304.
IEC/ISO 62304 was first released in 2006 and updated in 2015. The international standard, which both the EU and the United States use, regulates the development and maintenance of medical device software. Its purpose is to reduce software-related risks and improve safety across the board.
There are nine parts to IEC/ISO 62304. They include:
Complying with IEC/ISO 62304 involves plenty of documentation and a strategic development cycle. The safety standards govern the software's entire lifecycle from initial development to obsolescence. As a result, it requires careful planning and detailed reporting over time.
Not all software is a medical device in the eyes of the FDA and CE. But those that fit the bill require much more regulatory work before hitting the market.
It's not always easy to register to meet compliance standards. When it comes to software as a medical device, there isn't much room for error. However, making sure that everything is up to par is crucial. Doing it right will avoid the potential of having your business shut down or, if you knowingly violate the law, possibly going to jail.
Voler Systems has the experience and knowledge needed to develop your device. We know and use proper design control for software and hardware products, and we know when to involve regulatory experts to ensure it is compliant with all guidelines and regulations. Contact us today to find out how to make your medical device or to find out if it is a medical device.