Citation: Mulcahy C, “Smart Drug Delivery: Pragmatic Approach Reduces Risk, Increases Innovation & Patient Adherence”. ONdrugDelivery Magazine, Issue 76 (Jun 2017), pp 62-66.

Getting patients to adhere to long-term therapy for asthma and chronic obstructive pulmonary disease remains a difficult issue to tackle. Conor Mulcahy discusses a smart inhaler which could help solve this problem.

“Connected drug delivery systems that provide actionable patient data can increase adherence and proper use through personalised reminders and instructions sent to a patient’s smartphone…”

Smart drug delivery systems hold the promise of personalised medicine as they take advantage of the medical “Internet of Things” to drive significant improvements in medication adherence, patient care and, ultimately, health outcomes. When it comes to chronic disease management, connected drug delivery is the key to modifying behaviours and reducing unnecessary healthcare costs.

The emergence of digital healthcare is beginning to change the status quo for device manufacturers seeking a more effective drug delivery method and faster route to company profits amid increasingly tough competition. Makers of inhalers to treat asthma and chronic obstructive pulmonary disease (COPD), in particular, are well positioned to challenge the existing state in long-term therapies by embedding integrated sensors into their devices to take remote patient monitoring to the next level. According to the Forum of International Respiratory Societies, about 400 million people worldwide suffer from asthma.1 The WHO estimates that more than 64 million people live with COPD globally.2 The prevalence of COPD, unfortunately, is on the rise and by 2020, is expected to become the third-leading cause of death worldwide.3 Therefore, the opportunity to improve adherence to medication is not just aimed at offering symptom relief but at saving lives.

Getting patients to adhere to long-term therapies, however, remains a major impediment to treatment success. The US FDA reports that medication is taken as prescribed only 50% of the time.4 Connected drug delivery systems that provide actionable patient data (Figure 1) can increase adherence and proper use through personalised reminders and instructions sent to a patient’s smartphone. Smart devices that securely and wirelessly transmit usage data are expected to drive major advancements in remote patient monitoring, which could save up to US$36 billion (£28 billion) globally by next year.5

Figure 1: Connected Eco system.


The smart inhaler market will reach $191 million worldwide by 2022, according to Allied Market Research.6 This represents an annual growth rate of more than 60%. Leading the charge are GSK, AstraZeneca and Novartis, as they are making notable progress through collaborations with device firms and technology companies to spur development of next-gen connected drug delivery systems.

GSK, the respiratory market world leader, is entering clinical trials to test a clipon sensor developed through collaboration with Propeller Health (Madison, WI, US), provider of an FDA-cleared digital health solution for improving outcomes in asthma and COPD. The sensor automatically collects and records data on the inhaler’s usage. This information is then wirelessly transmitted to a central data repository for analysis by GSK’s clinical researchers. Their goal is to determine how remote monitoring improves patient adherence by empowering them and their physicians to better understand the impact and management of the disease in daily life.

“For device makers seeking entry into the smart inhaler market, this case should offer useful insight into what is necessary to get to market quicker as going through FDA regulatory processes can take several years…”

AstraZeneca has begun a clinical trial in collaboration with Quintiles (Durham, NC, US), looking at the impact of mobile medication reminders for COPD sufferers. The programme will use a smart device, mobile app and cloud platform developed by Adherium (see this article), a digital health technology leader, to demonstrate how these devices improve medication adherence in patients with asthma and COPD. Meanwhile, Novartis has struck a technology partnership with Qualcomm to develop the first smart inhaler with integrated sensors. Novartis plans to launch its next-generation connect Breezhaler by 2019.

The emerging ecosystem for connected drug delivery systems spans a growing list of stakeholders, including original equipment device manufacturers (OEM), drug developers, human factors experts, mobile app developers, cloud platform providers, regulators, healthcare providers and – last, but certainly not least – patients. Clearing innumerable barriers to market entry requires a methodical, pragmatic product development approach, starting with the initial discovery phase where product requirements are conceptualised, vetted and refined in a culminating product requirements document (PRD) that forms the framework for design and development teams.

Fastidious attention to detail is also required during subsequent phases to ensure a smart device reaches the delivery stage at the lowest cost and risk. To illustrate further the potential opportunities and pitfalls of building a smart drug delivery system, Nypro (part of a Jabil company), commenced an internal project, called Ruby, which followed a pragmatic, best-practices approach from conception to proof-of-concept.

Ruby’s goal was to create a fully functional device without the actual drug, one that is capable of replicating how a smart inhaler is expected to work. The device would track patient usage and then transmit data from the user’s smartphone to a physician for further review and to promote adherence and improved inhalation function performance over time.


Even medical device companies with decades of experience in mechanically driven products can face major obstacles when making the move to a smart device. This is because the process introduces an entirely new set of product considerations, including:

  • Sensor integration
  • Connectivity
  • Mobile technology
  • Cloud technology.

The move to smart devices also requires a new way of thinking and modified approach to product planning. Embedding electronics presents a wealth of possibilities and serious considerations that affect lots of variables, not the least of which are privacy, risk management and budget. In addition, there’s a high probability of “scope creep” as it can be difficult to gauge what is required to add seemingly simple functionality to a device if the company has little to any expertise or background in electronics.

To simplify and demystify the process of building a smart inhaler, the Ruby project took a widely used inhaler typically used for asthma or COPD and devised an integrated sensor solution for guiding patients through the delivery of a proper drug dose. With the medical mantra “do no harm” as a guiding force, a team of specialists set out to define product requirements using a comprehensive discovery process.

While the discovery phase is typical in any medical device development project, the process becomes more complicated when addressing a connected drug delivery device. The amount of information that can be gathered is massive, which necessitates a rigorous review of each data point to identify which details are shared with the patient, physician, healthcare provider, regulator and other vital stakeholders. A thorough discovery process not only pinpoints the most valuable data points, it identifies the smart functionality that will deliver the most product value in the long run.

Phase I: Define Product Success

The initial discovery phase of any product development project is crucial as it enables the stakeholders to collaborate on defining what success should look like at the end of the project. Sounds simple, but this is often the most arduous and complicated part of the project. Not only is it imperative to scope out product requirements accurately, it’s critical to define intended business goals. There’s lots of input that needs to be collected, culled and analysed during this phase as multiple systems comprise any connected device.

During Ruby’s discovery phase, each constituent was polled to gain insight into potential technology solutions without losing sight of how that proposed capability would impact the business side. Following an exhaustive, iterative review process, a list of product requirements was developed and analysed, starting with seven primary capabilities, which quickly ballooned to encompass 20 types of functionality.

Arguably the hardest and longest phase of the four-step product development process, discovery generates a seemingly endless litany of questions, starting with:

  • What do you want the device to do and why?
  • What patient problems are you trying to solve with this connected device?
  • What are the device’s most important attributes?
  • What is most important to explain to patients?
  • How does the device communicate with the patient, physician, primary care provider and pharma company?
  • Are you communicating verbally or with read-outs?
  • What does the device need to connect to?

Each set of answers produces an entirely new set of questions that need to be addressed to create a comprehensive PRD. Every PRD follows a logical method of inquiry to identify priorities and eliminate ideas that don’t pass the “value” litmus test. If a capability doesn’t deliver value to the patient, or offer value to the business, it shouldn’t make it into the PRD. Removing it further into the process adds inordinate time, cost and risk.

For Ruby, the iterative process and continual analytical reviews helped set the stage for product design by enabling the team to reduce the initial list of 20 capabilities to six core solution areas, comprising:

  • Communication: Bluetooth low energy
  • Power Management: Device on/off
  • User Interaction: Capacitance touch
  • Device State: Lever with hall sensor
  • Inhalation Performance: During drug delivery
  • Software: Data movement and security

Figure 2: Pressure sensor location.

Phase II: Design for Manufacturing Success

An overarching design focus was determining which features might expedite or hinder mass production by applying a series of design for manufacturing and design for assembly principles. A cross-functional team of engineers, human factors specialists and software developers brainstormed hundreds of design concepts and applied different criteria to identify 10 or so options with the lowest cost and least risk. Equally important was understanding if any function could potentially interfere or impact another.

Decisions for some solution areas came faster and easier than others. For example, the team made the decision to use Bluetooth Low Energy for smart phone connectivity because it consumed the least power. The much tougher challenge, however, was determining how to address inhalation performance. After vetting a host of options for checking if the drug had been inhaled correctly, the team settled on the use of a pressure sensor, again because it carried the lowest risk.

In determining how the device would communicate with a smartphone, the team had to assess whether the device would be verbally smart or just connected. As all device makers have finite budgets for power management, the team spent a lot of time determining how best to maximise battery life. User interaction was given substantial consideration because the device had to be simple, easy to use and intuitive to improve and sustain patient adherence.

During the design phase, inhalation performance surfaced as the biggest challenge. Software development, another crucial area, involved a completely different set of requirements to address issues surrounding data privacy and patient confidentiality properly.

Figure 3: Sensor to Airflow algorithm.

Phase III: Test, Optimise, Test

During development, rapid iteration and continuous testing ensured that each function performed as expected. The ideal solution for each function doesn’t always make it into the final, developed product as the ultimate choices are ones that present the least risk and enable the product to be developed at the lowest landed cost.

For Ruby, a team of expert system architects addressed competing elements in the top 10 designs to isolate the three options with the greatest potential and least risk. The team performed a series of hazard analyses, working through failure modes for each option. As indicated previously, dealing with inhalation performance was problematic because its addition became a power and space issue.

Another concern was actual placement on the printed circuit board as it was important to locate the sensor as close to the air channel as possible. This meant putting it on the underside of the board, which went against typical, top-down PCB assembly rules.

As Figure 2 illustrates, the pressure sensor was integrated into the bottom of the PCB, and the top surface of the sensor co-incided with the current airflow boundary so it wouldn’t impact airflow. Additionally, the top cover of the device was thickened to 0.85 mm to mount the PCBA and not disrupt the existing airflow channels.

A related challenge that surfaced was the need to convert pressure sensor output numbers, which are relayed in milliamps to litre-per-minute as these are units physicians typically deal with. As Figure 3 shows, the team applied numerous formulae and algorithms to calculate air moving down the channel at different speeds and temperatures. Then those findings were translated into a format that would be meaningful and actionable for physicians.

Another priority was how to determine the optimal way to count each drug dose, which also had to sync with the device’s mechanical counter; the mechanical state of each operational step also needed to be tracked. For the proof-of-concept, the team wanted to count each dosing behaviour as well as trigger an alert when the stored dosage went below a certain threshold.

The development team considered multiple options before choosing a hall sensor as the index sensor to track the drug count. They also realised this approach would provide input to device orientation sensor, so data from the hall sensor could be linked seamlessly with other sensors and software logic to provide real-time device status updates.

Additionally, system architects added a six-axis sensor with an accelerometer and gyroscope to detect device motion as the inhaler must be held horizontally to dispense a good drug dose. Not only would this sensor support the requirement to improve proper dose delivery, it could prove helpful from a logistics standpoint as data would reveal if a device had been forcefully shaken, dropped or damaged prior to a patient receiving the device (Figure 4).

Aside from the assorted elements architected for the device, Ruby system architects navigated how each embedded sensor would communicate with the mobile application and how that app would synchronise with a cloud-based platform. To accomplish this, the team focused on the following core software solution areas:

  • Cloud server – patient dashboard
  • Mobile application – architecture, over-the-air upgrade capability and drug lot use check
  • Device firmware – shock/shake and device orientation, patient contact logic, inhalation/exhalation confirmation and environmental sensing.

It’s critical to look at the solution holistically as omitting a key piece of either the hardware or software at this stage would add inordinate time and expense once the product is manufactured. For instance, a last-minute decision to add digital certificates during the final development stage can derail the project altogether if the initial chipset for the product lacked the correct library support.

To avoid these kinds of disruptions, the Ruby team went through the detailed PRD and performed a line-by-line comparison to ensure functionality was aligned with expectations for the final proof-of-concept.

Figure 4: Sensor to track mechanical state.

Phase IV: Accelerate Time to Market

Thanks to the close collaboration of a cross-functional team that spanned product discovery, design and development disciplines, Ruby’s proof-of-concept was produced in about four months. The reference design illustrates technical innovation in design, development and next-generation disruptive advances.

For device makers seeking entry into the smart inhaler market, this case should offer useful insight into what is necessary to get to market quicker as going through FDA regulatory processes can take several years – smart inhalers will be subjected to extremely thorough and lengthy regulatory review.

It is therefore imperative that companies avoid sole-source suppliers and electronics components nearing end of life or not compliant with requirements such as Restriction of the Use of Certain Hazardous Substances (RoHS) or Registration, Evaluation, Authorisation and Restriction of Chemicals (REACH).

Having real-time access to digital supply chain data is also important. There’s an enormous wealth of information that can be collected, culled and analysed to inform engineering, sourcing and procurement in terms of sensor suppliers, product lifecycles, inventory levels, compliance and more.


In bringing smart inhalers to market, device makers need to reduce risk with each step by starting with the end goal in sight. The success of the Ruby proof-of-concept demonstrates that a pragmatic, multi-phase approach is the key to accelerating time to market, reducing risk and achieving the lowest landed cost.


  1. “Forum of International Respiratory Societies (FIRS) Calls for Better Access to Care and Medicines for Asthma”. FIRS Press Release, May 2, 2017.
  2. World Health Organization (WHO), COPD Fact Sheet, No.315, February 2011.
  3. Fitzgerald K, “COPD Projected to be Third-Leading Cause of Death by 2020”. Managed Healthcare Connect, Vol 11(11), November 14, 2014.
  4. “Why You Need to Take Your Medications as Prescribed or Instructed”, US FDA Special Feature, February 2016.
  5. Slabodkin G, “Remote patient monitoring to save $36B globally by 2018”. FierceHealthcare, July 17, 2013.
  6. “Smart Inhalers Market”. Allied Market Research, November 2016.

Comment on this article


W3 Total Cache is currently running in Pro version Development mode.