As connectivity features become increasingly prevalent, developers are tasked with accounting for regulatory implications in increasingly long-term plans.

Aidan Petrie, Ximedica

Let’s imagine a product that dispenses a drug for eczema. At its most basic, the dispenser is little more than a package for the primary drug container and so falls under some medical packaging and labeling standards with some scrutiny as to what materials or pathways are in contact with the drug.

But add intelligence to the product and now it knows how much was dispensed and at what time; perhaps it has a reminder function that lets the patient know when they should take the treatment. We could then send the use patterns to the cloud and have analytics compress the data so that a caregiver or physician could look at the patient’s adherence to the regimen and make proper recommendations.

Everything described in this scenario is already happening with some medications, providing real benefits to the patient and potential benefits to the health system as a whole. Although some of these features cost little to implement and bring to market, others will require years of development, validation, usability and cost-benefit trials ­ and cost an order of magnitude more to develop. Preemptively planning and managing this process can give clarity to the entire team and allow development teams to effectively to meet deadlines, plan resources and budget accurately.

(Network with Ximedica experts at DeviceTalks West, Dec. 11–12 in Orange County, Calif.) 

Connectivity and classification

Connected medical devices offer huge value to healthcare systems and services with their ability to transmit and analyze data, remotely monitor patient conditions, manage multivariable disease states and more. Navigating feature sets that keep a device within FDA’s Class I exempt designation or trigger a higher classification is critical, as it has vast implications on development cost and timeline.

Almost every device we work on now has some form of connectivity. Often, the classification on the device has been defined by the clinical purpose and risk profile of the device and the FDA has an existing categorization. Other times, determining the effect of connectivity on classification can make abiding by pre-existing regulations difficult. As more digital products are being developed with capabilities, analytics and processing outside of the physical product, growing risks and ambiguity exist alongside the benefits.

Class I and Class II triggers

From a development perspective, the cost and time variant between a Class I exempt and Class II device is huge. With the higher risk profile of Class II comes a mass of additional requirements for the development and manufacturing process. Device development now follows a process outlined by ISO 13485 and the FDA’s Quality System and cGMP regulations. These rigorous standards incorporate user needs and requirements, specifications, hazards analysis and a full risk-management process, design history files, documentation practices and a myriad of other controls that ensure that the device is developed safely. The device or system must also demonstrate its efficacy through validation studies and predicate equivalency. The ISO and FDA quality system requirements call into play a plethora of general and specific product safety standards, including the IEC 60601 series, 62366, 62304 (software validation), ICH Q6 and Q9 and more. Risk management (ISO 14971) cuts across all these standards, laying out a development process infused with attention to safety and risk mitigation.

Connected devices, particularly those used at home, draw from many already available or easily developed technologies to deliver value to their diverse users. But how does the entrepreneur know what features might trigger a benign product Class I exempt device to suddenly require adherence to a Class II standard?

Evaluate each feature, present or future

The ‘tail should not wag the dog,’ in that classifications should not determine the success of a product. To that end, we recommend an exercise that evaluates individual features against the regulatory implications and against the development consideration. This trifecta gives the developer the ability to offset the market value of features against the likely impact to cost and to take a strategic approach to deploying feature sets. Developing a multigenerational plan in which MVP meets FDA strategy allows a product to come to market with a low regulatory bar and introduce new features over time.

It is also worth noting the advantages to pursuing features that will move the app into Class II or higher territory. These richer, more impactful features and functions enable a digital health product to separate itself from the pack. Class I apps are everywhere, are not distinct from each other and, although they offer some value, don’t take real advantage of the power of digital devices.

Regulatory, marketing and development leads should work through a matrix set that ’line items’ individual features desired and then categorizes them as ‘no implication,’ ‘it depends,’ or ‘triggers a higher classification.’ Proper input from respective leads about whether a particular feature will affect the development schedule or affect regulatory considerations in this rapidly evolving area can help to ensure that a device is successful in its first market entry and make it easier to build in new features as they are ready.

In 1985, Aidan Petrie co-founded an IP development firm today known as Ximedica. In his role as chief innovation officer, Emeritus, Petrie drives innovation in Ximedica’s core markets of medical device development and consumer healthcare.