Work With Us

Designing an IoT Medical Device? Four Factors To Consider

Good product design considers how a product will be used, in what setting, and what the regulations affecting such usage might be.

Much the same holds true for medical devices, with additional caveats: medical devices need to clear a whole slew of additional, stringent verification and certification requirements. These conditions, whether they’re imposed by the FDA or other governing bodies, change depending on a variety of design parameters.

Given the maze of use cases and associated certifications, design of an electronic or IoT medical device typically takes longer and costs more than you think. Such complexities might tempt product designers to adopt the path of least resistance — but that isn’t always the shortest path to a completed project.

When you’re planning the design of your electronic or IoT medical device, it’s essential to think through these four factors:

single-use versus reusable IoT medical devices

Single-Use Versus Reusable

A single-use medical device is used only once per patient and is disposed of following protocol, when done. A reusable medical device is one that’s used over and over again, although it might have single-use components. A reusable thermometer in a physician’s office with a single-use sheath is a good example of a mixed-use case.

Reusable devices have to be well-sealed, and have to be non-reactive to various disinfectants and withstand dust and shocks over time. Ingress Protection (IP) ratings typically determine the extent of a device’s ability to tolerate solids and water interfering with operation. For example, a rating of IP67 means the device has a solid ingress rating of 6, protected against dust, no ingress permitted; and a water rating of 7, protected against immersion in water up to 1 meter for 30 minutes. (Read more about IP ratings.)

For battery-powered devices, there is a whole host of associated certifications required to ensure that the device will stay functional during use, and can withstand the rigors of cleaning.

Some sanitization methods also involve extreme temperature cycling (autoclave), so if that is needed, it can dramatically affect the technologies used in the device. Electronics don’t generally like living outside of a temperature range from -40 to 70C, without taking significant measures. Other certification tests can be done for shock and vibration sensitivity and durability.

For battery-powered devices, there is a whole host of associated certifications required to ensure that the device will stay functional during use, and can withstand the rigors of cleaning. Differences between single use (primary) and reusable (secondary) cells can be significant, and affect storage life of single use products, performance under load, and shipping. Some required certifications worth knowing about include ANSI 60601-1 for medical devices, UN38.3 for shipping, IEC62485-X for safety, and IEC 60086 for primary cells.

The amount of capital expenditure needed to manufacture a device will also dictate if the device should be single-use or reusable. Often, manufacturers will make the part that’s exposed to the patient (as in the temperature sheath example, above) single-use while the main unit stays reusable.

The definition of what you might think is ‘single-use’ might be stretched here as well: Building a device that can simply be thrown away after use may be a significant cost savings in terms of development cost, unit cost, maintenance, and cleaning.

For example, in Trice’s MiEye joint inspection device, the probe, with integrated optics, camera element, canula, and interface cable, is disposable, which makes it easier to use, and cheaper to maintain than a larger unit where the camera element and fiber optics are sanitized and reused each time. In this instance, throwing away a camera is cheaper than cleaning.

Firmware and software needed for IoT medical devices

Firmware and Software Needed

Because medical device certification is significantly complex, companies will often use specific software and document management solutions — such as Greenlight Guru — to document the iterative prototyping, testing, and design process for 510K certifications needed along the way.

It’s important to not start the certification and verification process too early; you can easily get mired in the documentation that must accompany each step. Wait to start the validation and verification processes needed for certification until you have only a few potential changes to the device. Testing of your proposed solution should be fairly far along; you want to know the device will not change significantly before getting into document control.

It’s important to not start the certification and verification process too early; you can easily get mired in the documentation that must accompany each step.

You would want the device to move from an alpha to a beta stage — and be nearly ready for production — before you consider taking it to record control. For smaller companies or start-ups, it’s a good idea to partner with a third-party consultant or services vendor who can help guide and manage the documentation process and provide you a template for managing complex records.

Security under HIPAA for IoT medical devices

Security Under HIPAA

Because medical devices measure and collect patient health information, healthcare organizations that use them are responsible for that data’s security, according to the Health Insurance Portability and Accountability Act (HIPAA).

This security requirement gets even more complicated when it comes to connected medical devices, which relay patient information to a central collection source over a Wi-Fi connection. An IoT medical device must also check off boxes for safe data transmission and storage. If a hospital uses the IoT medical device to capture patient health information, relays it to a third-party vendor for data analysis or to store in the cloud, each step of this data gathering and analysis process must meet a stringent set of encryption requirements.

This security requirement gets even more complicated when it comes to connected medical devices, which relay patient information to a central collection source over a Wi-Fi connection.

A reasonable rule of thumb is that all associated markers connecting a patient to the corresponding data must be stripped down before transmission. This means “Peter Goodman’s” vitals might be relayed from an IoT thermometer but only as Patient 1234 (for example) so as to maintain confidentiality. You have to collect the patient data in an abstract way with a unique identifier that is not correlated directly with the patient until it gets linked back within the healthcare provider records system.

Mobile applications that access patient data must also address these security requirements: you have to answer architectural concerns about how the medical device is providing data, and how the app is collecting and processing patient data securely, and in a fashion that does not identify the patient.

An IoT medical device should be built on a secure hardware platform from the ground up; it’s very hard to bake the security back in once the device is already designed. This usually means including a secure element in the hardware itself to store encryption keys, and uniquely identify the device. Keys to secure device communications should be managed from the device being built in manufacturing, through provisioning for use and distribution, and into service for an end user.

Not managing the security of the device from design through delivery exposes potential risk to being compromised — and additional liability that has a higher possibility of exploit in the medical space. A single compromised design could end a company in the medical space quickly; planning ahead to avoid it is your best choice.

certification standards for IoT medical devices

Certification Standards

While the labor investment required to conform to certification standards should not dictate medical device design, it is nevertheless important for device manufacturers to understand how their product’s end use and design will dictate the certification process.

In addition to the IP ratings, the FDA classifies medical devices as Class I, Class II, or Class III. Class I have a history of safe use and pose minimal risk to the patient. Class II devices need additional special controls such as mandatory performance standards (here’s where IP comes in). Class III must meet the most stringent safety controls since they might pose a potential risk if not used properly. Artificial hips or silicone breast implants fall under this class.

Class II and III will also need to file a 510(k) pre-market notification submission, which the FDA reviews before the design can go to market. This notification must check off a long laundry list of parameters, including extensive details about related hardware and software development.

Unlike consumer devices, the provenance, or origin, of any software components used in a device must also be shown to be safe and tested to be certified. In today’s development world of complex communications and interface standards, this is no small or inexpensive constraint; specialized operating systems and software need to be used in order to be able to verify safe operation, either built from the ground up, and verified, or licensed from specialized providers that work in the medical software space.

Medical device design must also factor in a whole range of additional certification requirements that may not be immediately obvious: a device that plugs into a wall will need a power supply certified for medical use — and may require a battery backup. The user interface must be compatible with standards for sounds, and indicators — IEC60601-8. There are requirements for tolerances to static electricity and cleaning fluids ingress as well as levels of fire resistance. IEC and FDA standards govern most of these parameters.

Seek Help! That’s What We’re Here For

The design of medical devices is a long and complex process with various paths to final market use. This is especially the case for IoT medical devices, which add challenges in product design, security, software implementation, and certification.

Planning is essential: Determine the role the device will play in the IoT healthcare ecosystem it is intended for. What data needs to be collected? Where does it need to be relayed, and how will it be analyzed? For what outcomes? All of this information drives the cost model and development expenses involved in delivering a product to market.

It’s a good idea to recruit professionals who understand the unique conditions that medical devices must meet so you can focus on larger-picture goals.

Read about our expertise in developing Medical Products and IoT Products.