Adding Connectivity to Your Medical Device

By Eric Soederberg
April 25, 2016


• Categories: 04-Product Design & Development, 05-Quality/Regulatory

Adding a network data connection to your medical device may not only promote your device into the echelons of modern connected or ‘IoT’ (internet of things) devices, but it could also push your company into a whole new value delivery model.  A move from the presently dominant ship-and-done model to the newer “ship, monitor, and update regularly” model may be required. This is not a new model for gaming apps developers, but it’s radically new for regulated medical devices that require thorough verification and validation (V&V) before changes can be implemented in the field. Adding connectivity to your device also changes your solution from a device to a system with all of the broader system considerations this brings. This article explores some of the benefits and challenges related to connecting medical devices to external networks and provides an overview of how to address many of these challenges.

The Benefits

The use-cases for your device largely determine the number and types of benefits derived from network connections. For devices used outside of a clinical setting, access to the internet is straightforward, either directly via a built-in WiFi transceiver or cell modem, or through a smartphone or connected tablet using Bluetooth. The network connections allow manufacturers to stay engaged with the patient and/or caregiver in a number of ways, throughout the device lifecycle. Collected usage or compliance data can be made available to those concerned with the patient’s care. Questions such as—Did grandpa take his meds? Did Jimmy refill his insulin pump? Did mom do her breathing exercises?— can be answered from anywhere at any time.  Usage data can be stored securely in the cloud to prevent loss and allow both individual access and population-wide analytics.

Manufacturers can monitor how the device is used (e.g., menu paths taken, canceled operations) to evaluate the ease of use or potential use errors. Cybersecurity related events can be monitored to enable fast responses and reduce exposure to cyber attacks. Software updates can be pushed to the devices directly from the manufacturer.

For connected devices with no access to the internet there are still benefits. Easy and error-free entry of device data into an EHR is one obvious benefit. Wireless connections to smartphones or tablets enable smaller, easier to use or more comfortable-to-wear devices by simplifying on-device user interfaces (UIs). The smartphone or tablet can perform the device configuration and allow more complex data presentation on the display. Connected devices can also integrate with other medical devices or data sources to enhance treatment or detect ailments. If disposables or consumables are used with a device, then automatic ordering of replacements can be built into the system and help prevent the use of counterfeit consumables.

The Challenges

While the benefits are huge, the challenges are commensurately great.

Cybersecurity. In recent months cybersecurity has topped the news and the worry list for healthcare providers (HCPs). In February, Blue Cross Anthem was hacked and millions of patient records were released. Recent ransomware cases have also made the news.

There are two sides to cybersecurity: Safety and privacy.

On the safety front, to date no one has been physically harmed due to cyber hacking of medical devices. However given the documented vulnerabilities found in medical devices, patient harm remains a real possibility. The FDA issued guidelines that in effect require manufacturers to address cybersecurity, both for new submissions, and in existing products as part of the mandated CAPA and risk management design control regulations.

On the privacy front, personal health information (PHI) is valuable to cyber criminals and sought after by organized crime to aid in their nefarious activities (gaining access to other’s property, and stealing it). Data security is mandated by regulations under the HHS/OCR, specifically the HITECH and HIPAA regulations.

Sensitive to these issues, HCPs put devices through rigorous cybersecurity evaluations and tests before connecting them to their networks. Some HCPs are writing procurement agreements that hold medical device manufacturers responsible for the costs of cyber breaches caused by the manufacturer’s supplied devices. Manufacturers cannot allow hospital networks to be compromised through their devices.

All of the cybersecurity vulnerabilities for a given device cannot be known when the device first ships. Moving forward, the FDA and HCPs expect manufacturers to monitor for newly discovered vulnerabilities and update the affected software to prevent those vulnerabilities from being exploited. These expectations covers all devices with programmable elements, however, connected devices are far more susceptible to cybersecurity attacks and will require more support throughout the device’s lifecycle to address newly found vulnerabilities.

Connecting to EHRs. “Walled Gardens” (a closed model) describes the prevalent model for the healthcare database and electronic health record (EHR) systems in the United States, and most “gardens” are unique. A particular HCP can pull data from external sources into EHRs using middleware, a third party provider, or custom written by the HCP, but there is little standardization as to how the information is presented. As Christina Farup, vice president of DePuy Synthes, stated at the 2016 MassMEDIC Annual Conference, “You’ve spoken to one hospital, and you’ve spoken to one hospital.”

From inside an HCP’s firewall, third-party middleware providers that team up with the major EMR providers can deliver a secure solution. However, they will need to be convinced there is a market for your device before they will invest in writing a conduit for your device.

There are many standards, including some new promising cross platform protocols (keep an eye on the HL7 group’s new FHIR), but we cannot expect consistency from one HCP to another in the near future. One thing is clear: Few HCPs are willing to go to a manufacturer’s website to gather patient data. Furthermore, doctors do not want patient data that they did not ask for:  Unsolicited patient data is considered out of context, not therapeutically relevant, and a potential liability. For data resulting from prescribed measurements or metrics, some HCPs are willing to pull data into their EHRs from trusted platforms such as Apple’s HealthKit or Microsoft’s HealthVault, but even these platforms are not established standards yet.

Design. The design of connected device systems requires many special considerations. At the top of this list is keeping the patient safe regardless of what happens to the network connection, or what potentially erroneous signals are sent over a network connection. Smartphones and other external platforms are largely outside of the control of the medical device manufacturer and therefore can be used to augment patient care, but cannot be counted on as a sole means to sustain life or protect a patient from harm.

Human factors and user experiences need to be carefully evaluated early in the design phase. Doctors are not likely to prescribe the use of your device if the reports are not useful to them. Power management for battery-powered devices is critical. Choosing where to store the patient data and how to robustly synchronize the data to the appropriate cloud database is crucial. The architecture and design of the webserver and use of web applications need to be optimized to maintain high reliability for a reasonable monthly web server costs.

Smartphone and tablet apps need to run on multiple platforms (e.g., multiple iOS and Android software versions) and potentially on dozens of smartphone or tablet hardware configurations and platforms. The app development simulators are good, but too “clean” to use for validation of a medical app.

Lifecycle support. Lifecycle support will include software updates and V&V for all of the system components including the device firmware, any smartphone or similar apps, and any server-based web apps. Manufacturers of cloud-connected devices will have to support server management, administration of users, administration of devices, and data management including data access authorization. Code to monitor cybersecurity related events is needed for all of these applications as well.

Even though the FDA has stated it will allow changes to improve cybersecurity to be shipped without the FDA’s preapproval, full design verification is still required before implementing a change in the field; all medical design control regulations still apply.

A Smart Approach

It’s a System; no longer just a device, and the system has implications for one’s entire value proposition and revenue model.

Step One. Stakeholders from across the business must to work together to understand the costs and benefits of the various approaches appropriate to your unique situation and define the requirements for the system. Remember that the support costs may not stop after the devices are shipped, and in return, there may be offsetting remuneration for the ongoing services provided. As input to the system requirements, this is also a good time to gather end-user inputs and to start the human factors analysis to make sure your investment is targeting a real need in an appropriate manner.

Step Two.  Architect the full solution that will meet all of the system constraints and will comply with the many, and sometimes, competing regulatory guidance. Design-in the appropriate device use and health monitoring functions with the infrastructure needed to monitor and act on the data. There are many third-party SAS solutions available for data collection in the cloud to be considered. Remember to evaluate the ongoing costs, the control, access, and ownership of the data stored there. We prefer to use the resources available in AWS (Amazon web services) to implement highly secure and cost effective cloud solutions. We have a toolkit solution on the shelf that we use for our clients.

Here is where the details of the connection approach need to be defined—for example, exactly how will your device interface to, or make data available to, EHRs, and in which institutions. Consult with doctors as to the appropriate format for any data provided. Talk to the hospital IT managers for methods of connection to their EHR and possibly their accounting systems. Risk analysis is a critical part of the architecture design, and many options and tradeoffs need to be considered to optimize patient safety, cybersecurity, availability, and cost constraints.

Step Three.  Implement the system components following compliant and proven robust development processes. Design and implement maintainable code, comply with coding standards, and comment well to aid in maintenance.

Step Four. Verify and validate the subsystems (e.g., the device, supporting apps and any web applications). It is likely you will want to rerun the V&V many times as updates are required, so use automated tools for code analysis, automated tests frameworks, and procedures for verification and validation.

Step Five. Integrate the system; verify and validate the system. Cyber penetration and fuzz testing should be considered in addition to the standard medical suite of tests to the system requirements. For apps, the SDK simulators are not good enough—they’re too clean (i.e., they do not have Verizon’s code or other third-party apps running). Test against all likely target platforms using, for example, the AWS device farm. Keep in mind that you cannot test every smartphone or tablet configuration, so you still need to monitor your app’s performance in the field.

Post Launch. Post-launch activities include the activities that were defined in steps one and two, and the tools developed as part of the system to implement these activities. If you are moving or storing PHI, then make sure you have appropriate HIPAA controls in place and business associate agreements (BAAs) with any service providers enlisted to work with PHI on your behalf. Be sure to review the FDA’s “Postmarket Management of Cybersecurity in Medical Devices” draft guidance, which, among other things, encourages your involvement in the NH-ISAC (National Health Information Sharing & Analysis Center) to monitor for newly discovered cybersecurity threats and vulnerabilities.