Launching medical device software is more expensive and time-consuming than other digital health programs, with strict regulations existing around the world. One of the questions that crops up regularly in our discussions with pharma is whether a planned patient support program will be classified as a medical device, with certain components often being borderline. In this post, we discuss how, in many cases, the best approach is to launch a program that is as close to a medical device as possible without crossing the line, leaving the door open for medical device components to be added later on.

Launching (Almost) Medical Device Software

Regulations regarding medical device software vary from country to country but are largely similar in major markets such as the US and EU. The US and EU, along with the UK, China, Japan, and several other countries, are members of the IMDRF, a group that aims to harmonize global medical device regulations.

For example, one consistent requirement for medical device software is an ISO 13485-certified quality management system (QMS). Similarly, the definitions used to describe what constitutes software as a medical device are broadly similar in both the FDA’s guidelines and those used in the EU’s Medical Device Regulation (MDR). Software designed to diagnose, treat, or prevent diseases in individuals, for example, is strictly defined as a medical device. Similarly, software that works alongside medical devices (like smart injection devices, for example), is classed as an ‘accessory for a medical device’ under MDR and is still subject to regulation.

Medical device software is subject to pre-market review and approval and post-market surveillance, meaning it requires greater resources dedicated to it throughout the product lifecycle.

At smartpatient, we run medical device software on MyTherapy for pharma partners as part of a comprehensive patient support program, with the versatility of the platform making it ideal for a variety of use cases.

Often, however, we realize in our discussion with pharma that it is not strictly necessary to launch a program as medical device software. Typically, only a specific component is considered a medical device, such as the connectivity to a physical device, while the rest of the program does not meet the criteria.

Gaining approval for this single component is still a costly and time-consuming undertaking, and typically holds back the launch of the entire program. In such situations, therefore, we find ourselves often recommending that programs are launched at a point where they are not quite considered medical device software or accessories for a medical device.

On top of the regular MyTherapy feature set, such a program can still contain modules tailored to support patients on specific treatments, such as treatment initiation support, automated regimen setup, and educational content.

Software with such features falls just short of being classed as a medical device, meaning a program can be launched faster and at a lower cost, while still delivering the majority of its value to users. Furthermore, because regulations are broadly similar across much of the world, this approach allows for ‘almost’ medical device software to be scaled to different markets. This, again, helps pharma derive the maximum value from a program in the most efficient manner.

The Door is Open for Adding Medical Device Components

This concept of launching a program that does not cross the line of becoming a medical device is in line with our attitude toward taking a value-based approach to digital patient support.

For the majority of users, a lot of value is derived from the tailored modules described above, along with adherence support, symptom and side effect tracking, and other features that come out of the box for every PSP running on MyTherapy. Getting the maximum value to users as efficiently as possible is in line with our “lean MVP” (minimum viable product) philosophy.

This approach takes advantage of the fact that software can be constantly refined, improved, and added to. Thus, if adding a medical device component is still desired, its development can occur in parallel to the program launch, as can the admin that goes into gaining approval from regulatory bodies. Upon completion, the medical device component can simply be added to the program via an update.

While we find this is counter-intuitive to many people in the pharma industry, for whom a typical product must be 100% completed and in its final state before hitting the market, it is widely recognized as an intelligent approach to software development.

It also allows pharma to continuously reassess its plans by gathering data and evidence sooner. If a program is launched with medical device software from the outset, the time and money spent on its development cannot be recovered should it fail to deliver value. However, launching with a lean MPV, understanding user needs and behavior, and making decisions relating to the development of medical device components based on this additional information is a more prudent path to take.

Discuss Your Plans for Launching (Almost) Medical Device Software

If the topics discussed in this blog are relevant to you and your plans for launching a digital patient support program, we would love to discuss how you can take a value-based approach and whether or not you should be launching medical device software. Click here to get in touch with us.