Citation: Kiely M, Marsden L, Stringer P, Boyle D, “Medical Device Design Strategy for a Connected Future”. ONdrugDelivery, Issue 115 (Dec 2020), pp 14–18.

Michael Kiely, Laura Marsden, Peter Stringer, and David Boyle discuss the design challenges at the electromechanical interface and encourage manufacturers to adopt a standardised approach for connecting medical devices to the cloud.

“With millions of devices potentially impacted, it’s vital that both engineers and developers establish comprehensive system-level understanding of how these components will come together at assembly.”

The Internet of Things (IoT) refers to the billions of everyday devices that are now connected to the internet. Our cars, home appliances, phones and fitness armbands have all been transformed into smart devices, capturing data and delivering analysis in an holistic feedback and analysis loop. In healthcare, this combination of digital-sensing technology and cloud computing has dramatically accelerated growth in the Internet of Medical Things (IoMT).

Today’s medical device market demands the most up-to-date technology, with connectivity to the cloud now considered a “must have” capability for digital healthcare product solutions. As such, medical devices now enable new models of engagement between patient and provider, enhancing the exchange of vital metrics and health information at both the personal and population level of healthcare delivery. Better informed, time-efficient, safe and clinically effective outcomes are at the heart of the promise in digital healthcare. The numbers bear this out: the global connected healthcare market is expected to reach a market value of around US$6.6 billion (£4.9 billion) by 2027 and is anticipated to grow at a compound annual growth rate (CAGR) of around 11% in terms of revenue from 2020 to 2027.1

Manufacturing variability is always a primary concern within the tightly regulated healthcare industry. Medical device product development, at minimum, requires subject matter expert (SME) input for both electronics and mechanical componentry. Connected devices also require expertise related to software, automation and user experience. With millions of devices potentially impacted, it’s vital that both engineers and developers establish comprehensive system-level understanding of how these components will come together at assembly (Figure 1).

Figure 1: The electromechanical interface.


Let’s consider the mechanics of a push button as an example. As one of the primary interfaces for the user with the device, it is important that the button achieves the correct tactile and visual feedback. This gives the user confidence that the action has been carried out correctly and is important for the overall quality and “feel” of the device. How many times have you been frustrated by buttons getting stuck or having a sticky action? Your initial reaction to the product is to question the quality of its build. Consistent button action doesn’t just happen; it requires thorough design work up front and an excellent understanding of both the electrical and the mechanical component specifications – particularly when manufacturing at high volumes.

The example shown (Figure 2) is a simplified rendering of a switch mounted on a printed circuit board assembly (PCBA). Actuation of the switch is accomplished by a mechanical button positioned at the top of the device. Design requires that it is flush to the surface of the outer case. To achieve the correct tactile feedback and continuous surface appearance, controlling the distance between the electrical switch and the button is critical.

Figure 2: Factors contributing to button actuation profile accuracy.

Mounting the switch on the board itself (S2 in Figure 2) is another consideration, and accuracy is paramount. This position may have a large tolerance band in a typical reflow soldering process which is used for high-volume PCBA manufacture. For post-soldering inspection purposes, a larger contact pad and solder amount is preferable to confirm correct electrical connection. However, this will require a large tolerance for the end position of the surface-mounted switch post reflow, as it may land anywhere in the large contact pad. Therefore, the smaller the contact pad, the better the positional accuracy. There is a trade-off with inspection requirements and the placement accuracy of the automated line to land on a smaller contact pad. For fine placement accuracy, a mechanical mounting can be used but this will add to PCBA cost and complexity. In a real-world example, there are likely to be many more interacting components, such as sensors and connections ports, that will only add to this complexity.

Cut-out tolerances must also be accounted for: PCBs may be manufactured to a range of tolerance standards, and it is challenging to achieve fine tolerances at high volumes. The accuracy of the cut-out will be largely dependent on the routing process used. Typical cut-out tolerances here can be in the range of ±0.1–0.2 mm, which can be significant in the stack up of tolerances. One potential solution for reducing offset inaccuracies could be drilling the PCBA mounting holes at the same time as the panel tooling holes.


“Whichever method is selected, it is important to understand the challenges and limitations of the measurement technology and the potential impact on accuracy.”

Tolerance of the switch itself is another primary factor. Achieving tighter tolerances typically requires integration of expensive, high-end or bespoke switches. Tolerances are dependent upon the materials used, the design of the tool (injection-moulded parts) and the distance to the measurement datums on the parts. All of these must be optimised, for example by applying design-for-manufacturing (DfM) principles, and addressed to meet end-tolerance requirements (Figure 3).

A checklist of considerations is as follows:

  • Moulding tolerances of the plastic casing
  • Relative position of the PCB retention features
  • Geometry of the PCB retention features
  • Position of the button mounting
  • Thickness of the button
  • Wall thickness of the housing.

Figure 3: Reduction of out-of-specification devices after the application of design for manufacturing (DfM) principles.

At a system level, when all these sources of variation from both the electronic and mechanical components are taken into account, one can begin to understand how critical it is to have cross-functional expertise when optimising a connected device design for high-volume manufacture.


Data collection is at the heart of design strategies for connected devices. It’s critical to optimise a sensor’s placement – or an array of sensors – in tandem with the device electronics and firmware. For example, in a connected autoinjector there’s a wealth of insight to be gleaned through tracking and measuring plunger travel. Depending on the level of detail and accuracy required, plunger travel data can be captured by sensors in a variety of ways. In a previous ONdrugDelivery article, we discussed sensor integration in a trial smart inhaler.2

What can be detected by plunger travel?

  • Needle shield removal
  • Contact with skin
  • Start of plunger travel
  • End of plunger travel
  • Incomplete delivery of medication
  • Full dose administration (when coupled with a skin contact sensor – e.g. capacitive or push switch)
  • Occlusion detection
  • Delivery rate
  • Anomalies in the delivery profile.

Once the items to be detected have been identified, it is necessary to understand the technology requirements and how to incorporate them into the design of the device. The range of technologies for tracking plunger position include mechanical switches, hall sensors, inductive measurements and optical sensing (Figure 4).

Figure 4: Examples of sensor options for measuring plunger travel.

Whichever method is selected, it is important to understand the challenges and limitations of the measurement technology and the potential impact on accuracy. Direct measurement of the stopper position within the syringe is not usually feasible, so an analogue must be used – e.g. the back of the plunger or movement of another part of the system. The sensing method chosen must be precise enough to provide accurate dosing information, while also allowing for a reasonable tolerance in accuracy of placement of the sensor itself.

Available locations within a device to site and integrate electronics may be limited. The integration of electronics to the area of least sensitivity to variation should be prioritised in the design. A detailed tolerance analysis will be critical at this stage to understand if the accuracy requirement can be met, taking into account the sensor accuracy, the sensor placement accuracy and the variation within the device itself.

Component tolerances, component interactions and assembly all contribute to potential variations in autoinjector product performance. Some sources of variation that should be considered and optimised prior to sensor selection are:

  • Drug fill volume
  • Syringe barrel internal volume dimensions
  • Syringe barrel mounting area dimensions
  • Needle dimensions
  • Plunger stopper dimensions
  • Plunger stopper assembly position
  • Change in plunger stopper position due to transport
  • Change in properties of all device elements due to temperature and humidity
  • Mechanical position of the syringe in the device
  • Mechanical position of the plunger component
  • Injection mechanism forces
  • Frictional effects.

Accommodating all these considerations will ensure collection of the most accurate drug delivery information from the autoinjector, which sets up the next step: connecting the device for communication to the cloud.


Connected devices serve a wide array of use cases and purposes. As with the device’s electromechanical design, a breadth of SMEs with different skillsets should be engaged to work across the full solution, over different timelines and phases. Variability is again a primary challenge and must be accounted for across the design and development workflow.

“Component tolerances, component interactions and assembly all contribute to potential variations in autoinjector product performance.”

A standardised approach is ideal; without it, each device solution becomes a time-intensive and bespoke effort, requiring the creation of new firmware for every device. Backend development must be accommodated from the start – not delayed – as that would risk the need to solve connection issues when the devices are connected to their solution. These issues can include needing to use code workarounds and patches to address unanticipated connectivity problems or require a return to the device firmware embedded code. This can be challenging at the best of times and too late to address at others.

There are many benefits to be gained from a standardised approach and it is in fact a differentiator across many industries. In the plumbing industry, for example, some professional plumbers will only quote and engage in a job if the homeowner or designer will be installing Grohe faucets. Grohe has become known for its “quick connect coupling” system throughout its portfolio of products. This standardisation allows installation time, tools and other connection supplies to become reliably predictable. The professional is prepared every time. The accuracy of quoting a job becomes a seamlessly smooth transaction and potential pitfalls or lost time and money are mitigated.

Taking this approach with connected devices involves the creation of a firmware architecture that is scalable to different microcontrollers and maintains reference code libraries of different sensors and device types. A communication protocol is required to enable the device and solution to communicate the telemetry and attributes of the device and what they require to interface and communicate with the solution.

Not long ago, getting a personal computer up and running had users scrambling for installation instructions for the drivers for each unique device, (mouse, keyboard and printer) to enable connection and operation. Today, all of this happens by simply plugging in the device or pairing over a WiFi connection. It’s become as simple as a handshake. The devices communicate a representative model of their capabilities and this allows the operating system to reference a known model and understand how to interact with the device (Figure 5).

Figure 5: Communications handshakes among potential players of the IoMT.

Microsoft’s Azure is an excellent example of a service product that has the power to standardise across the industry for connected medical devices. Its service removes the requirement for extensive embedded code in exchange for a common open modelling language between IoMT device and IoMT application. Just as described with peripheral devices, this creates a model for compatibility across the platform.

Azure’s plug and play modelling language is based on JSON-LD and RDF.3 Each device model has a unique identifier or digital twin model identification (DTMI) number. Each model identity (ID) in the library has a set of interfaces. The device and cloud solutions interface at the different levels. At each level, the communication protocol enables the devices to “advertise” their attributes. In other words, they are able to answer all the questions about the device regarding on-board sensors, how they communicate and what they need to connect.

Interactions, such as the device’s digital twin model running “search” functions to query and understand the device’s attributes, how it functions and communicates, enable the system to self-regulate and improve. These solutions also help create an appropriate environment, dashboards or insights from the device’s data, enabling users to send management commands to the device, ultimately, guaranteeing a seamless ease of connection to any compatible platform solution using this approach.

Ease of connection is a huge advantage. Not only does it remove the burden of complex embedded code, it also simplifies calibration of life-sciences diagnostics instrumentation. In today’s communication protocols, software maintenance and calibration are built in, freeing the lab technician to focus on understanding and applying laboratory results, not software upgrades. IoMT designers and developers can apply the bulk of time and effort where it will provide the greatest impact and value: the use cases and insights that data and applied analytics provide.

The ability to model interactions and build libraries and protocols enriched by metadata will only increase with the volume of devices added and integrated. All these data collection and communication enhancements will provide more leverage in the pursuit of improving individual wellness, disease state management and population health.

Our future, and increasingly our present, has us working with connected and interoperable ecosystems, providing a clearinghouse of shared and structured data. Devices connected to patient, provider and the cloud are building out networks of complex connections and applied analytics – enabling deeper insights and problem solving for improved patient care.


  1. “Connected Healthcare Market Size, Share, Growth, Forecast 2020 – 2027”. Acumen Research and Consulting, May 5, 2020.
  2. Mulcahy C, “Smart Drug Delivery: Pragmatic Approach Reduces Risk, Increases Innovation & Patient Adherence”. ONdrugDelivery, Issue 76 (June 2017) pp 62–66.
  3. Web Page, JSON-LD. (, Accessed December 2020).

Comment on this article