Everyone is connected, and now our things are becoming connected: thermostats, lights, door locks, cars, cameras, baby monitors, and a plethora of other gadgets.
Some connect to a server in the cloud, some connect to mobile devices, some connect to each other, and some connect to everything. It was only 25 years ago that the Web really started to take off. Today, the Web gives us information at our fingertips, perhaps not as it was envisioned a few decades ago, but we’ve reached a point of widespread connectivity and accessibility.
Depending on who you listen to, year-over-year growth of the Internet of Things (IoT) could slow to 40% in 2020 and have a dollar value in the hundreds of billions. We are still in the early days of rapid expansion and, as always, there are issues—enough such that we have the ‘‘IoT Cybersecurity Improvement Act of 2017’’ appearing in the news. As we think about the projected growth of IoT in particular, this is probably a good thing.
The growth of IoT is driving advancements in base technologies, products, and consumer expectations, and the effects it has on our daily lives will continue to evolve. If you need to be convinced of this, shut down your internet access for a few days.
How does IoT intersect with medical devices?
Imagine that you could be in deep contact with your medical device throughout its life cycle. Now imagine that your team is able to observe when and how the device is used, and further, how it performs. Along with the benefits of this oversight, consider having a cost-effective path to modify your device as your team identifies issues. Imagine the potential serviceability of the device, the impact on consumables, the new usage models, and the opportunities for new business models.
The affordability of IoT technologies and the growth of consumer expectations will continue to change the landscape. Does this mean that every medical device needs to be connected?
To plan for this future, we will look at the value that can be realized, how we address security, how we think about service, what the data is and how we realize its value, and what technologies are relevant.
What is the value?
We first need to understand the value of IoT and who realizes it. A connected tongue depressor is probably meaningless; but what about a connected tongue depressor dispenser, with a fulfilment model that means it will never be empty? The clinic never needs to worry about reordering. Meanwhile, the vendor takes on the burden of monitoring quantity and ensuring that customers have an adequate supply. This is a trivial example affecting the “availability” of the device, but it’s also an example of how connecting a device “container” could change how a device is supplied. In this illustration, the clinic gets the benefit of not having to worry about ordering, and the manufacturer gets the benefit of being able to monitor customer use and getting to leverage automatic “reordering.” There isn’t a direct change to the device, but there are changes in availability to a service being provided by the manufacturer.
More direct value propositions?
There are a number of areas to explore. In the case of a therapeutic device, or a device which monitors patient therapy compliance, there is clear value to both the caregiver and the patient. The caregiver has data on patient compliance and has an input to help assess the effectiveness of treatment. The patient can be provided a gentle reminder, a message from the caregiver, or other feedback to better engage them. In some cases, a family member can be included in the information/feedback loop to assist in compliance.
For any device, the ability to monitor it in the field, getting to understand how it is being used and how it is performing, can provide real value to the manufacturer. There are sometimes unseen obstacles to adoption. By building in monitoring and reporting back to the manufacturer, issues can be detected early and possible correction can be applied. Perhaps training was inadequate or the device has an issue in the environment, but remote monitoring is less expensive than a survey and can provide far better data. This is clearly of value to the manufacturer.
There will likely be a few different dimensions that can provide value. The evolution of these capabilities will enhance what we are doing now, and enable treatment and feedback that were not previously possible.
What is the downstream value?
As we collect data via IoT devices, curation will become significant. Longitudinal data in a specific treatment will be invaluable to understand efficacy. To realize this value, we must address consent, privacy, and security. An example is the progression of chronic conditions which may be affected by both treatment and lifestyle. Not only is this of interest in aggregate for research, it can be of immediate interest to the patient.
What about security?
Before people start to fear security, they should remember that many millions of credit card transactions happen online every day. With the development of protection methods and protocols over the years, we seem to have achieved an acceptable level of security.
Now, we need to think about securing the function and data of a connected device at the start of the product cycle. We can bifurcate into two main areas: patient information and cybersecurity.
A good definition of patient information is any medical information that can be tied to a patient or reasonably small set of patients. If your product is used only on people over 100 years of age, you have identifiable patient information. Likewise, if you store a patient name with the data, you have identifiable patient information.
Patient information needs to be thought of with the same diligence as we would think about financial information. If you do not have or need this information, do not generate or store it. This is the simplest solution.
If you do need this information, it must be secured and managed appropriately. Keep the smallest set of data you need on your device, and make sure it does not “leak out” in the form of logging or debug information. This is a common issue that comes to light when patient data is in system or application logs through the product development lifecycle and is never removed.
Retrofitting the management of patient information is expensive. Considering it as part of the system from the start can make this a straightforward effort.
Cybersecurity involves the function of devices. How can it be compromised to do harm? It is wonderful that we can upgrade a device after it has left our premises, but can someone else?
The best way to safeguard our device against being comprised is to ensure that, no matter how malevolent the software might be, the device cannot cause harm. By considering this through the early design process, we can contain these functions, perhaps even ensuring that critical functions are not “upgradeable.”
What about upgrading?
A very attractive aspect of this extensive connectivity is the ability to upgrade our device remotely. With straightforward security measures in place, this can mean significant savings in cost. We need to ensure that our processes can accommodate this kind of deployment and track it appropriately. There are a number of details to manage, including identifying the version of the product and making sure our traceability is adequate, but, like security, consider and address these issues at the early design phase.
What data do we need to collect? What data do we need to provide?
Considering these questions is key to realizing value. Their solutions can affect the main function of the device, other aspects of its function, the way consumables are handled, and business models that we have yet to conceive. They are also product specific and need to be defined as we ideate product features. Consider a case involving chronic condition treatment. This would have us not only collecting data from the patient, but also providing feedback to that patient and his/her caregiver. By understanding the level of compliance achieved, we can better measure the effects of the therapy.
How do we ensure data consistency?
In the short term, the data will likely be consistent. Throughout the life cycle of the product, however, this will not be the case. A common source of issue will be tacit knowledge of what the data means. To illustrate, say we define “any treatment length of less than 10 minutes means it was aborted and should not be considered.” Later, we decide that if a treatment lasted less than one minute, it means it was aborted. We are now reinterpreting the data that was previously one to 10minutes, which might not be valid. A number of changes like this can transform valuable data into a transactional garbage heap. Once we take the time to define its value, we need to document changes to our data in the same way that we track changes to other components. Doing so will help to make sure we preserve the longitudinal value.
How does it affect product quality?
There will likely be data collected that contains details on device operation, and it will often provide insight into unanticipated behaviours. This frequently leads to a pattern through the development cycle involving the analysis and modification of data logged. With forethought, this will allow for instrumentation once the product gets off the bench, which can yield a wealth of data that allows engineering to monitor function with a level of detail not otherwise available. Through these means, issues that are buried can come to light very early in the life of the product.
What technologies should I be using?
Bluetooth X, Wi-Fi, and Custom Radios. Bluetooth LE is everywhere and is a great low-power solution with low to moderate data requirements. Wi-Fi is reliable and can provide high data throughput, but consumes more power. Then we have a variety of custom and semi-custom solutions that can provide different speed, throughput, and power consumption. As a general rule, a longer range requires more power, and a higher data rate require more power. When we have portable devices, power usage will be one of the key issues we will need to consider.
Sometimes the problem is simple and clear: “We need to interface to a system using Wi-Fi and a rest protocol with TLS and the device is plugged into the wall.” Other times, requirements are not so clear and we need to dig further.
The best path is to define the usage environment. Is real-time data necessary, or can it be cached and transmitted in bulk? How much data needs to flow in what directions, and how important is power efficiency? Next, we need to understand the communication paths, determining which components need to communicate with other components. With this information, deriving the technology requirements becomes more straightforward and we can select appropriate communication technologies.
How does this affect my project team?
This level of integration will require teams to be able to access some additional capabilities. Security and communications are commonly overlooked, as are data definition and analysis. When the value propositions are defined, highlight how these areas can be addressed.
How do we get going?
Start dreaming about what your product’s world would look like if you could understand every detail throughout its lifetime. New value propositions will precipitate from these thoughts.