Grasp ‘Software as a Medical Device’ regulation for success in the US mHealth market

MHealth Software Regulation: part II

Following on from our review of the European regulation surrounding the rapid growing mHealth market and specifically the development of complementary Smartphone Apps, such as Abingdon Health’s AppDx Smartphone lateral flow reader, in part two of our blog we take a closer look at the regulations within the U.S. market, the largest diagnostic market globally.

As with the European market, the regulation is complex and needs to be considered from the outset of the development project. So let’s look at some of the key areas to consider with a specific focus on our market, lateral flow testing, and the integration of smartphone apps into diagnostic solutions.

Understanding compliance and the US regulatory landscape

The International Medical Device Regulators Forum (IMDRF) defines Software as a Medical Device (SaMD) as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.” Which explains why lateral flow rapid tests that use complementary readers fall under this category.

The use of SaMD is continuing to increase, with this area projected to grow at a CAGR of 85.41% by 2025 (knowledge-sourcing.com). So, whether you’re offering SaMD yourself as part of a new product, or looking to use an “off-the-shelf” platform, you must be aware of the regulations, the quality systems and standards, and ensure that you or your chosen SaMD provider are meeting regulatory expectations continuously.

When introducing a new SaMD product in the US market, you must apply for clearance with the Food and Drug Administration (FDA). The governing documents you need to ensure compliance with are:

• Title 21 of the Code of Federal Regulations, and in particular:
• 21 CFR Part 11, Electronic Records, Electronic Signatures
• 21 CFR Part 820 Quality System Regulation; be able to demonstrate you’re meeting the Good Manufacturing Practice requirements (CGMP) – these were first authorised in section 520(f) of the Federal Food, Drug, and Cosmetic Act, and were later codified under part 820.

Internationally Recognised Standards

In addition to the GMP requirements in the CFR 21 Part 820, manufacturers of medical devices and SaMD providers are expected to develop and implement a Quality System and obtain certification.

There are several internationally recognised mechanisms that can help with this.

• ISO13485 – the quality standard stating the requirements of the Quality Management System (QMS) for the design and manufacture of Medical Devices. Companies are expected to have an ISO13485 Certification as an industry standard.
• IEC 62304 outlines the recommended way of developing software. IEC 62304 applies to the development and maintenance of medical device software when:
  • Software is itself a medical device.
  • Software is used as a component, part, or accessory of a medical device.
  • Software is used in the production of a medical device.

To go above and beyond:

• ISO14971 (2019) – an ISO standard for the application of risk management to medical devices.

Data management and cyber security needs to be water tight

To have your device cleared and commercialised, you need to have FDA clearance. However, this simply covers the bare minimum you need to achieve to introduce a new product into the market.

With so many companies having fallen victim to their own negligence, it would be foolish to ignore things like:

• 21 CFR Part 801 Labelling
• 21 CFR Part 803 Medical device reporting
• 21 CFR Part 814 Premarket approval
• 21 CFR Part 822 Post market surveillance
• 21 CFR Part 830 Unique device identification
• 21 CFR Part 860 Medical device classification procedures

We would recommend having a mechanism for recalling products and informing the right parties in a timely manner – for example, having draft documents ready to be completed, signed and released – perhaps as part of ISO14971 de-risked process.

Also, cyber security is becoming of equal importance to SaMD product functionality. Therefore, the FDA is introducing a new standard: Content of Premarket Submissions for Management of Cyber Security in Medical Devices. The aim is to negate security breaches with the ‘increasing use of wireless, Internet- and network- connected devices, portable media (e.g. USB or CD), and the frequent electronic exchange of medical device-related health information.’

Don’t forget data protection

We considered the EU’s data protection law, GDPR, in part one of this blog series and whilst there is no direct equivalent in the United States important consideration should be given to both federal laws, such as HIPAA Privacy Rule which establishes national standards to protect individuals’ medical records and other personal health information, and also state laws. For example, the California Consumer Privacy Act implemented in January 2020, which gives consumers control over the personal information companies collect, store and often share with other enterprises.

Stay one step ahead

In summary, the regulatory landscape is complex and evolving. It’s critical to integrate your regulatory plan into your overall project plan. Technical decisions made during the development process need to consider regulatory implications. At Abingdon Health, we understand the importance of this and our in-house regulatory team can work with you to ensure you keep one step ahead. MHealth is a fantastic opportunity to accelerate the adoption of rapid tests, but it adds a layer of complexity. Be prepared!

View mHealth Software Regulation: part I here

Credit: content contribution from Bond Digital Health Ltd.