Regulated digital health explained: What you need to know to stay compliant [Sponsored]

There’s currently a lot of buzz around regulations for digital health, particularly in Europe with the EU Medical Device Regulations (MDR) which went into effect May 26 after a one year delay due to the Covid-19 pandemic. Digital health thought leader Mark Tarby, who serves as BrightInsight’s vice president of regulatory and quality management systems, shared his take on what the new regulations will mean for connected devices, Software as a Medical Device (SaMD), and the go-to market strategies for the companies behind them.

EU Medical Device Regulations (MDR)

Among some of the notable changes included in the EU MDR are:

• Stricter control for high-risk devices via a new pre-market scrutiny mechanism involving a pool of experts within the EU
• Reinforce the designation and process criteria for oversight of notified bodies
• A new risk classification system for in vitro diagnostic medical devices in line with international guidance
• Improved transparency through a database and device traceability based on new device identification
• Additional rules on clinical evidence and post-market surveillance requirements for manufacturers

Tarby said one of the biggest impacts from EU MDR will be implementation of a larger and improved EUDAMED database which will simplify the exchange of data on medical devices for patients, users, suppliers, manufacturers and regulators of medical devices. Improving coordination between EU countries for vigilance and post market surveillance will lead to more confidence in the patient experience across the EU. 

But the new regulations also pose a new set of challenges. Tarby noted that some Class I products that were previously CE marked for self declaration now require notified body involvement to obtain the CE mark because their classification has been upgraded, potentially adding to the time required to launch the products.  A notified body is an organization designated by an EU member state to assess devices for conformity to essential technical requirements before being placed on the market in the EU.  

Another change is that the requirements for clinical data, both pre-market and post-market, and the review of clinical data have been enhanced.  For example, expert panels will be created for all Class III and certain Class IIB devices. The expert panel reviews will increase the medical, technical, and scientific scrutiny of high-risk devices to ensure that safety and efficacy are established for a more robust overview of the clinical data. These experts will also play a role in post-market surveillance.

Another feature of the EU MDR is the addition of a unique device identification system, which has been established in the U.S. market for some time. A new code or UDI-DI will be required whenever there is a modification that changes either the original performance, the safety of the software, or the interpretation of data. The modifications include new or modified algorithms, database structures, operating platforms,  architecture, user interfaces or new channels for interoperability.

BrightInsight has processes and procedures to monitor these changes and work with customers to implement them, Tarby said.

“When a company does change the software devices, it’s important to make sure these changes are addressed appropriately. Managing changes like these are built into our Quality Management System (QMS) procedures.  If a platform provider doesn’t have a robust QMS, it is very costly to develop one and to remediate their design documentation to support the requirements.” 

BrightInsight has tracked the development of the EU MDR for years, making it well positioned to advise clients on how to effectively integrate necessary changes to ensure their devices and medical device software are compliant. 

“We conducted a thorough gap analysis of our Quality Management System and of our products to identify required changes,” Tarby noted. “We put together a plan and then implemented any changes that were required. If there were changes to customers’ product classifications, we would help them effectively plan for any changes that would be needed. For example, if a product moved to a Class II designation it would require a notified body assessment.”

One of the key decisions that companies need to make is whether they can get by with a Medical Device Data System (MDDS), an FDA term in the U.S., which is an unregulated platform for storing and transferring data and displaying medical device data— or should the company opt for a platform that supports regulated software? The answer hinges on the intended use of the data.

“If you go beyond your initial unregulated use case, you’re likely getting into regulated medical device functionality…and the platform your software is built on needs to have the appropriate quality and security design requirements built in,” Tarby said. “It needs to meet the appropriate regulations and standards and have the requisite risk design verification and validation testing documentation available to support regulated products.”

An example offered in a recent whitepaper from BrightInsight underscores the contrast between an unregulated and regulated use case.

“Let’s say a patient is wearing a Class 2 (FDA) medical device that transmits data to caregivers. If a doctor were to review raw patient data and make a clinical decision about it, that is likely an unregulated use case. However, if you were to develop a Software as a Medical Device (SaMD) algorithm that analyzes data on the platform and makes clinical recommendations, that is a regulated use case.”

As the whitepaper points out, it is important to consider that the intended use of the data is likely to evolve over time. Another example cited in the whitepaper is a companion app that tracks device usage, which is an unregulated use case. But perhaps the company will want to later add alerts such as dosing recommendations to engage users based on a patient’s data analyzed on the platform. That would transform the app to a regulated Software as a Medical Device.

Tarby pointed out that use cases tend to expand, not contract, over time. Although at the start of a project the use case may be very limited, subsequent use cases tend to expand the functionality and can shift the functions beyond unregulated intended uses. 

“That’s why it’s important that the platform the software is built on has the appropriate quality design requirements built into it, otherwise you have to do remediation which can be time consuming, expensive and require major design changes to the platform itself just to support things such as privacy and security.”

How biopharma and medtech companies should think about enforcement discretion in the U.S.

A broader set of challenges for companies to address is navigating the gray areas of enforcement discretion in the U.S. market. 

“From a connected medical device (CMD) perspective, it’s important that your system supports Software as a Medical Device, specifically. From a quality management system perspective, it’s important that companies address all the global requirements because things can differ across regions,” Tarby said. “You need to make sure that your system is set up to continually monitor all the regulatory changes and that they’re communicated, adopted and implemented into your quality management system. For BrightInsight, it’s critical to keep up to speed with these changes and that’s built into our processes and procedures.” 

Tarby also stressed the need for companies to be engaged with regulators so that they can properly classify your software.

“I think it’s important to interact with the regulatory bodies. In the U.S., you can do a 513(g) submission to confirm your device classification with the FDA and avoid any downstream delays. Notified Bodies (in the EU market) can also provide guidance regarding your product in the EU. You need to make sure you stay up to date on the changing regulations and guidance.”  

The new regulations could also impact medtech companies’ decision about which markets to seek clearance for their devices first. Historically, some would try to bring their products to market in the EU first since the pathway may be faster than securing FDA approval. Tarby noted that although logistics and timing drove some of these decisions in the past, it is possible that MDR could change this trend. 

“With the MDR it could impact some of those choices, especially if the product were now moved to a higher classification,” noted Tarby. “Some of the time to market advantages may have been reduced with the implementation of the new MDR.” 

Good Practice (GxP) in the life sciences industries 

GxP is an abbreviated term that refers to good practice regulations and standards. For example: Good Manufacturing Practice (GMP), Good Laboratory Practice (GLP), and Good Clinical Practice GCP), and many others across different industries.  Adherence to these guidelines promotes quality, ensuring products meet their intended use. 

“GxP is kind of a catch-all phrase for things like Good Manufacturing Practice, good clinical practice, good laboratory practice,” said Tarby. “There are a lot of areas that are covered under that term. Regulated software has to be designed to be compliant from day one, developed within a certified quality management system. It’s important to understand that upfront and to have that in place so that everything that is needed is there when you do your submissions.”

Navigating digital health compliance complexity

As biopharma and medtech companies plan, build and launch digital health products, it is important to understand the regulatory, privacy and security issues upfront, with an eye toward the need to stay on top of regulation and device classification changes in order to ensure ongoing compliance. 

Photo: NicoElNinom, Getty Images

Source: https://medcitynews.com/2021/07/regulated-digital-health-explained-what-you-need-to-know-to-stay-compliant/