Citation: Dahmani A, “Think Beyond the Device: The Many Sides to Connectivity”. ONdrugDelivery Magazine, Issue 87 (Jun 2018), pp 34-36.

In ONdrugDelivery Magazine the technical design and capabilities of connected drug delivery devices are often discussed. However, there are far more factors in bringing a product to market to consider than this alone. In this article, Alexander Dahmani sheds light on some of these considerations.

At first glance, connectivity can appear to be simply a technical issue. However, the challenges and requisite decisions extend far beyond design and engineering. In fact, let’s not even touch upon the technical issues, seeing as they’ve been well and often covered elsewhere. This article is meant to broaden the scope that device manufacturers and pharmaceutical companies consider when it comes to connected drug delivery devices, helping stakeholders better navigate this new and exciting space.


One of the greatest concerns echoed by various industry stakeholders is the perceived regulatory challenges associated with connected drug delivery devices. No pharmaceutical company wants to take on additional regulatory burdens, above and beyond what is already required for their combination product. However, having a deep regulatory understanding can inform strategic product decisions and greatly alleviate or even avoid additional regulatory hurdles when adopting connectivity. This section is not intended as regulatory advice, but rather a summary of recent regulatory guidance and how it might impact connected drug delivery devices, companion software and associated medications.

“One of the major impacts that regulation has on connected drug delivery devices is the inherent conflict between long regulatory timelines (associated with medical devices and combination products) and the pace of technological change (in electronics and software)…”

One of the major impacts that regulation has on connected drug delivery devices is the inherent conflict between long regulatory timelines (associated with medical devices and combination products) and the pace of technological change (in electronics and software). By the time you launch a connected drug delivery device, the technology incorporated in it is likely out of date. That’s why it’s important to consider future-proofing the design of the device to benefit from the pace of technological innovation.

According to guidance issued by the US FDA on 25th, October 2017,1 significant changes can be made to a medical device without the need for regulatory submission in many instances. The regulatory threshold for submission defined in the guidance applies to device changes that significantly affect the safety, effectiveness, or intended use of the device. Therefore, future-proofing a connected drug delivery device can be achieved by designing the embedded systems in a way that does not impact the safety or effectiveness of the device. In other words, incorporating the sensors and connectivity to exclusively and passively collect data, instead of actively impacting the core functionality (i.e. drug delivery) or overall usability of the device. This allows more rapid incorporation of new sensors, wireless modules, antennas, processors, batteries, etc. The FDA also specifies how the above guidance affects combination products:

“This guidance does not specifically address combination products, such as drug/device or biologic/device combinations; however, the general principles and concepts described herein may be helpful to manufacturers in determining whether submission of a 510(k) is required for changes to device constituent parts of combination products.”

For certain types of devices, a future-proof design just isn’t possible. For example, a closed-loop insulin delivery system will rely on the sensors and wireless connectivity to actively control the delivery of insulin, by communicating with a glucose monitoring device (and potentially a companion software application). However, if the intended use of the drug delivery device does not depend on the sensors and connectivity, then it is advisable to keep these subsystems completely isolated from the core functionality. Following this strategy has further benefits when it comes to firmware and companion software. Applying a similar risk management-based approach, there should be no issue updating the firmware to comply with changes in wireless standards (e.g. cellular carrier requirements) or to benefit from advances in wireless technologies.

Regulatory bodies have also recently clarified their view on companion software for connected devices, allowing device designers to further isolate the software from the core functionality of the device. According to the 21st Century Cures Act Section 3060(a)2 which amended the Food Drugs & Cosmetics Act Section 502: “The term device, as defined in section 201(h), shall not include a software function that is intended … for transferring, storing, converting formats, or displaying clinical laboratory test or other device data and results, findings by a health care professional with respect to such data and results, general information about such findings, and general background information about such laboratory test or other device, unless such function is intended to interpret or analyse clinical laboratory test or other device data, results, and findings.”

This means connected drug delivery devices may be developed, tested and approved independently from a companion software application, if the software application only interacts with the device to collect data and mark a dose as taken. This regulatory separation of connected device and companion software enables rapid software innovation, in addition to broader device integration across various software platforms. The next section goes into more detail regarding the companion software space and factors to consider in relation to connected drug delivery devices.


“Translating device data into dosing data can be more complex and nuanced than it may seem…”

The core relationship between a connected drug delivery device and companion software is the automated dose logging feature. Translating device data into dosing data can be more complex and nuanced than it may seem. It usually involves taking one or more data points indirectly related to the drug delivery event and making a determination as to whether the dose was consumed. In some instances, it even involves estimating how much of the dose was consumed. It’s important to be rigorous in how the device classifies a dosing event because improper classification can confuse the user and lead to unfavourable events after the fact. It’s also advisable to have the firmware on the device make the classification decision, in order to separate the functionality from the companion software. If the companion software is receiving raw sensor data and transforming it into dosing data, a regulated relationship with the connected drug delivery device may have been formed (depending on the nature and level of the data transformation). This isn’t a problem if the device and software are designed to perform additional regulated features, such as a dose calculation (e.g. bolus calculator) or dose titration system.

While the relationship between connected drug delivery devices and the companion software is largely limited to medication tracking, the overall functionality of the companion software shouldn’t be. Engagement with the app will most certainly be lower if the patient is required to use additional apps to serve their needs. Many patients may be on multiple medications, and may be interested in tracking additional metrics such as symptoms, mood, activity, nutrition, etc. A companion app shouldn’t be viewed simply as an interface for the patient to view device data or a portal to transmit device data to the cloud. Companion software should be viewed as an opportunity to enhance the patient experience and an important contributor to medication and disease management.

Data security and privacy can’t be overlooked either. It’s important to position the connected device and companion software as a valuable tool designed to help the patient, not as a monitoring tool designed to spy on the patient.

User consent for sharing the data is required and more users are likely to consent when they see value. One strategy that may help improve patient opt-in is to link data sharing to a free support service, that way they don’t view the flow of data as a one-way agreement with no value in return. Sharing data can enable the delivery of more relevant and personalised content and support. Another strategy that may improve opt-in is to frame data sharing as a philanthropic effort, leading to insights that will help improve existing therapies or design better therapies for fellow patients in the future. Building a more productive and continuous relationship between the patient and their healthcare provider is another valuable outcome associated with data sharing.


Even after spending the time and effort ensuring you have the right connected offering (drug delivery device + companion software), there still needs to be a scalable way to deploy it. This can be a challenge for widely distributed products, the sort that pharmaceutical companies lose control over as they travel through multiple channels. Independent of the distribution channels and networks, the healthcare provider is an important stakeholder in the adoption of a connected offering. Even if the connected device doesn’t require a prescription, patients trust their healthcare provider’s advice and will most likely follow their recommendation in terms of using such a device. Therefore, marketing the connected offering to the physician in order to generate awareness and demand is an important first step. Making it easy for the patient to share their data with the healthcare provider can help improve demand.

“For some therapeutic categories and indications, in particular those where the medication is affordable and the medical consequences of poor adherence are expensive, payers may be willing to cover some of the costs…”

Patient support programmes may be another way to generate awareness and demand, by interacting with the patient directly. Connected offerings can be incorporated as part of such a programme; a welcome kit containing the device and app instructions can be distributed to the patient after they enrol. Patient support services also represent a scalable way to help onboard patients, including training the patients how to set up the device, sync it to the app and use the different features of the app. This can occur over the phone or in-person, depending on the level of service offered with the pharmaceutical product and complexity of the connected offering. In certain instances, a reusable device can replace the training device and automate some of the onboarding process. The connected device can report back training results, perhaps even having periodic training modes to keep the patient’s technique honed.


For some therapeutic categories and indications, in particular those where the medication is affordable and the medical consequences of poor adherence are expensive, payers may be willing to cover some of the costs. Diabetes is a good example of where payers have a strong financial incentive to improve medication adherence in order to reduce hospitalisations and prevent medical complications. However, for biologics and other speciality drugs, where the dominant administration paradigm is already at-home self-administration (e.g. when, looking at US health insurance records, the annual pharmacy benefits far outweigh the medical benefits), connected offerings and patient services will need to be covered as an expense under the “gross to net” of the pharma companies. Therefore, a business case needs to exist for pharma to allocate some of its margins to cover the incremental costs associated with connectivity and companion software. Upon consideration, there are three main business cases that make connectivity worthy of adoption by pharma companies.

Lifecycle Management

The first business case is lifecycle management of an established brand that may be coming off patent or simply facing increased competition. A connected offering can differentiate a product by making it easier and more convenient for the patient to use. This is important from both the patient and healthcare provider perspective. However, it is the least compelling from the payer perspective, who historically does not pay more for additional convenience.

Real-World Evidence

The second business case is the collection of real-world evidence. It is valuable for pharmaceutical companies to understand how their drug is being used and how it’s performing in the real world. The data collected from connected devices can be used internally to inform how products are designed and developed in the future. The data can also be used externally to contract with payers by demonstrating real-world performance. This is becoming ever more important. Payers are now expecting and demanding real-world evidence, no longer accepting clinical trial data as sufficient. Also regulators are starting to consider real-world evidence as an acceptable means for expanding a product’s label, without requiring additional clinical trials across each indication.2

Improved Drug Performance

The third and most important business case is to improve drug performance. Improving adherence, persistence and clinical outcomes should be the primary goal for connected delivery devices. By making medications easier to remember and easier to use, patients should be more able to manage their treatment regimens. In addition, connected devices provide a real-time, accurate and dose-level mechanism for targeting support efforts. Educational content and behavioural interventions can now be tailored and delivered to the right patient at the right time. These technologies will become even more critical as pharma companies gradually take on more risk, shifting from rebates to value-based contracts.


It’s an exciting time in the pharmaceutical industry, as new technologies arrive in the face of new challenges and new business models. Device manufacturers, software developers and pharmaceutical companies must all be aligned and in close collaboration in order to see connected drug delivery devices successfully developed, deployed and used. This requires a different, expanded set of capabilities and stakeholders than traditional drug delivery devices. However, if done properly, the additional cost and complexity will be well worth it. Soon enough, “connectivity” won’t even be a topic. Devices won’t be “smart”. They will just be, and we will all be better off for it.


  1. “Deciding When to Submit a 510(k) for a Change to an Existing Device”. US FDA Guidance, October 2017.
  2. “H.R.34 – 21st Century Cures Act”. US Congress, December 2016.