Why we need to think differently about drug delivery device connectivity

For manufacturers of consumer products, it’s now often considered important to have a connected device to keep up with competition and also to be seen as innovative. Launching a first generation connected device is an opportunity to explore how users respond to new propositions. Early adopters get treated as, and often brag about being, ‘Beta testers’ providing feedback on bugs and instances where the product is a cause of frustration. In the majority of cases, frequent software updates have to be rolled out to fix performance issues based on user feedback. Products that are well received in the market by early adopters can be redesigned and released as second generation products to encourage mass appeal.

These connected consumer devices generally have a short lifespan and can therefore be designed to use the communications technologies and protocols relevant at that time.

Early adopters of some connected devices can be exposed to a number of risks. The best product isn’t necessarily the one that succeeds, which can leave some early adopters having to change horses when their initial choice gets dropped due to lack of commercial success (think VHS vs. Betamax, or Blue Ray vs. HD DVD). Some connected consumer products introduce other potential downsides. Minimal attention may be paid to wider security issues, seemingly innocuous products, such as a connected doorbell, can provide hackers with access to your home network if the device’s security is easily breached. What’s more, a connected device’s online ecosystem may be critical to the usefulness of the product and if that shuts down, your nice shiny hardware may become a nice shiny doorstop (think Google’s Nest shutting down the Revolv smart home ecosystem). Most connected devices are purchased as products and do not come with detailed service agreements guaranteeing online support for a long period of time.

That said, the consumer product development model is clearly working. This is evidenced by the diverse range of devices coming to the market. What’s more, this development model gets product to market fast, which is essential to gain market share, and maybe establish a new ecosystem.

For medical and pharmaceutical devices, connected devices are a very different proposition. To make it to market, new products need to be demonstrably safe and effective. Regulators demand extensive evidence of this. Likewise, it’s also imperative that medical devices are secure, to ensure both safety and confidentiality. Fears around data security and privacy are often far more critical than with consumer products. The idea of sharing intimate details of our state of health is incredibly unpalatable. The resulting security considerations put constraints on the technology selected and increase the development time. This must be offset against flexibility in the underlying communications system to allow support of multiple, often fluid, technologies for exchanging data with the outside world.

A connected device might send or receive data or control information, interact with remote devices, connect to a server over the internet or just exchange information between the device and a smartphone.

The ability to pass information to or from a drug delivery device opens up a number of interesting possibilities. For example, dose reminders, or sensors to monitor the patient’s condition for side effects or to evaluate the effect of regimen changes.

A connection to a smartphone also offers some other potential advantages. The relatively large, high resolution, display may be a better way of viewing information compared to a device display limited by the size of the product. Having the instructions on the phone can be helpful particularly if these were also available as videos or audio files. The ability to customise these messages to meet the user’s capabilities could be critical (information in the right language and level of complexity, in a format that can be interpreted). Links to other online resources (such as peer-to-peer forums, or details on complementary therapies) could also help compliance by educating the patient about their condition and treatment. Such advances, however, face many challenges.

It can be tempting to collect and present data simply because it is accessible. However, to avoid data overload, it is imperative that the data that is collected and presented is relevant, useful and accessible to everyone that interacts with it, whether they be patients, carers, nurses, doctors or payers.

Connected medical devices are often promoted as offering additional value to health care professionals by providing richer data on the health and condition of their patients. However, it is important to consider the time that health care providers have available to respond to the data that is collected on their behalf. Once multiple connected drug delivery devices start to enter the market, health care providers are unlikely to have the time to deal with a wide range of user interfaces on different device data portals, or the level of data that might be available.

The functionality of connected devices should be informed by a detailed understanding of the conditions that they have been designed to support. One place to start is by considering the use of the non-connected legacy version of the product. Observing and interviewing stakeholders can reveal rich insights. The international standard on medical device usability (ISO 62366-1) advocates the use of task analysis to describe current activity. This involves breaking down the activity into sub tasks, these sub tasks are then themselves broken down until base level operations are reached.

Each base-level task can be examined to assess the demands it places on the user at a sensory, cognitive and physical level.

This usability analysis will often throw up where additional or new information or features may support or reinforce a particular task. This analysis yields data that feeds into a table of information requirements for each task, enabling us to identify feature opportunities.

Unmet needs can sometimes also be highlighted from unexpected sources – such as the #WeAreNotWaiting social media and maker group. These groups of very tech savvy individuals are creating their own connected medical devices, often by combining off the shelf technologies with bespoke open source software. While they offer exciting insights into unmet needs, the solutions they are developing are only really accessible to those with a detailed understanding of technology. The open source nature of the technology, and the lack of formal regulation to assess for safety and efficacy, places users at a clear risk.

Thus, it is important to consider the feature set carefully, taking into account all stakeholders needs. A development path should be chosen that will lead to a safe, functional, efficacious and successful product. That means understanding the stakeholder needs, targeting the correct level of engagement, while not detracting from the core device functionality and not compromising device usability.

One approach is to map out the functionality of the system in a tabular form, allowing a direct comparison to be made between the legacy system and the proposed connected system. The table below is an example that identifies the information required to support each task, highlighting the source in the current system (shown in the blue). Having established the table for the current system, it is then extended to include alternative or additional information sources in the connected system (shown in the green columns)

The alternative or additional information sources can then be explored and summarised in a table of potential new features. Each potential new feature must be assessed and filtered based on the benefits, and potential risks, to the stakeholders. The process iterates because of the potential to introduce new risks but generates a reasoned, useful and safe set of features more likely to give rise to a successful product.

If connected medical devices are to stand the greatest chance of commercial success it is important that:

1. Development is based on a properly structured process aligned to the relevant standards (e.g. ISO 13485, EN 62304, EN 62366, ISO 14971).

2. The needs of the various stakeholders are understood.

3. A reasoned, useful and safe feature set to implement is established at the start of the design process and revisited throughout the development of the device.