The ABCs of Medical Device Software Compliance under EU Regulations 2017/745 and 2017/746 – April Komplin’s Presentation – Part 1

April Komplin is a valuable member of the Celegence team due to her expertise and highly successful career in Quality Management Systems and Regulatory Affairs. At her previous position at a medical device start up, she built their QMS from the ground up and the company is now ISO 13485:2016 certified and will achieve CE Marks for seven medical devices in 2021. Additionally, she covered compliance for 21 locations across North America for an In Vitro Diagnostic device manufacturer.

During our Medical Device Virtual Summit – 2021, April Komplin presented a feature presentation titled “The ABCs of Medical Device Software Compliance under EU Regulations 2017/745 and 2017/746.”

Why should you watch this video/read the transcript?

• To review the medical device software (MDSW) classifications and include a discussion of their implications under the MDR and IVDR
• To understand the key requirements for MDSW technical documentation under the MDR and IVDR, including the risk assessment, performance evaluation, and post-market surveillance plans

A full transcript of April Komplin’s presentation is available to download (and to read below) and just press play to watch the clip now. 

Medical device software is defined as software that is intended to be used alone or in combination for a purpose as specified in the definition of a medical device in the MDR or IVDR, regardless of whether the software is independent or driving or influencing the use of a device.

So, let’s talk about the two different options for placing your software on the market, which of course would be relevant to its functionality.

1. 1. Software as a Medical Device (SaMD): SaMD is a medical device in its own right. It must have a medical purpose on its own. It acts independently from medical device hardware.
   2. Software in a Medical Device (SiMD): SiMD is software incorporated into hardware that does not function on its own for a medical purpose or to achieve the device’s intended use. It is an integral component of a device. It is also termed embedded software. It drives the use of typically a (hardware) medical device. And again, it does not perform medical purposes on its own.

The term “standalone software” used in the MDD, is no longer used in the MDR.

Examples of Medical Device Software:

1. 1. • Cardiac monitoring software
      • IVD results interpretation software
      • Medical imaging software
      • Therapy/treatment planning software such as those for drugs or radio therapies

Examples of Non-Medical Device Software:

1. 1. • Fitness trackers
      • Software that is purely administrative and for record keeping
      • Insurance billing or admission software
      • Laboratory information systems (LIS) which wouldn’t include specialty models that may be developed that are unknown at this time
      • Software that does not meet the definition of a medical device or is not an accessory to a medical device

Software may be qualified as medical device software regardless of its operating location. For example, in the cloud directly on a computer, on a mobile phone, or incorporated into a device as a SiMD.

So there are two very important assessment questions for any software medical device manufacturer to start with. Does the device meet the definition of a Medical Device? So you want to be sure to consult the definitions found in both the MDR and the IVDR. Once you’ve moved past that question and answered “yes” to that question, ask yourself, is the device regulated under the MDR or the IVDR? and of course, this is incorporated into its intended use and its functionalities.

There are 10 implementing rules in the IVDR, which can be found in Annex 8, all are important, but the key implementing rules for software include application of the classification rules shall be governed by the intended purpose. If the device in question is intended to be used in combination with another device, the classification rules shall apply separately to each of the devices. Software which drives a device or influences the use of the device shall fall within the same class of the device. If the software is independent of any other device, it should be classified in its own right. If several classification rules apply to the same device, the rule resulting in a higher classification shall apply.

The MDR implementing rules can also be found in Annex 8 chapter 2. Application of the classification rules shall be governed by the intended purpose of the devices. Software, which drives or influences the use of a device, shall fall within the same class as the device. If the software is independent of any other device, it shall be classified in its own right. So, there’s your SaMD. If several rules, or if, within the same rule, several sub-rules, apply to the same device based on the device’s intended purpose, the strictest rule and sub-rule resulting in a higher classification shall apply.

Just a question here. Have you begun your MDR transition planning and allocated a notified body under the MDR? Those who have their devices under the MDR are a little bit luckier as there are currently 20 notified bodies designated under the MDR.

MDR classification rules can be found in Annex 8 chapter 3. There’s potential for any of the 22 classification rules to apply to your device.

Software is classified in its own right (SaMD) or it takes the classification of the device it is incorporated in.

For example:

1. 1. • Software may be classified under MDR rule 2, if incorporated in a blood or tissue storage device
      • Software may be classified under MDR rule 10, if it is part of a therapeutic radiology device
      • Software may be classified under MDR rule 15, this is class 2B if used for contraception
      • Software may be classified under rule 22, which would be a class 3 device, if it is an active therapeutic device that significantly determines patient management

Now the MDR has its own specific rule for software, whereas the MDD did not have a specific rule for software. That rule is rule 10 under the MDR, and that rule reads software intended to provide information, which if used to make decisions with diagnosis or therapeutic purposes is classified as class 2a, except if such decisions have an impact that may cause:

1. 1. • death or an irreversible deterioration of a person’s state of health, in which case it is in class 3 or
      • a serious deterioration of a person’s state of health or a surgical intervention, in which case it is classified as class 2b

Other parts of this rule include software intended to monitor physiological processes, which is classified as class 2a. Except, if it is intended for the monitoring of vital physiological parameters, where the nature of variations of these parameters is such that it could result in immediate danger to the patient, in which case it is classified as class 2b. And the final part of rule 11 – all other software is classified as class 1.

Have you documented your classification, justification, and regulatory strategy? That is, of course, a requirement of both the MDR and the IVDR.

Let’s start with section 4. So section 4 is divided into 3 subsections.

Quality Management System (QMS): The manufacturer of medical device software shall demonstrate the ability to provide software that consistently meets customer requirements and applicable regulatory requirements. A QMS for EU that conforms to ISO 1345:2016 will ensure manufacturers adhere to this requirement.

Risk Management: The manufacturer shall apply a risk management process complying with ISO 14971. And again, risk management goes into further detail in section seven of this standard.

Safety Software Classification: It reads – manufacturers must assign a software safety class.

The EU harmonized standard is currently EN 62304:2006. You can of course choose to use the IEC 62304:2006 plus the 2015 amendment as long as you justify that as the state of art in your risk management file.

It is essential for medical device software manufacturers to have a copy of this standard. Ensure you also have the 2015 amendment available as important updates are made.

Items previously only applicable to software safety classes, B and C are now also applicable to safety class A. This would include:

1. 1. • Use of the software resolution process
      • Retesting after changes
      • Documenting known residual anomalies
      • Archiving software
      • Ensuring reliable delivery of released software
      • Applying the requirements early in development

Manufacturers must assign a safety class to their software device. MDR and IVDR implementation does not change the requirements of IEC 62304. Although there may be manufacturers who are previously self-certified, who have not yet fully applied the standard and need to do so to their legacy devices.

It’s recommended to create a control document, which is typically a report against your compliance to IEC 62304 that is maintained within your quality management system.

Software medical device manufacturers should complete and maintain an IEC 62304 gap analysis. This gap assessment or gap analysis should be created against the device’s safety class. As there are different requirements throughout the standard based on whether the device is safety class A, B or C.

IEC 62304 section 4 requires a gap analysis and follow up activities. The 2015 amendment has added this requirement for legacy devices. For example here, section 4.4 of the standard reads taking the perform gap analysis into account, the manufacturer will evaluate the potential reduction in risk resulting from the generation of missing deliverables and associated activities and create a plan to perform activities and generate deliverables to close these gaps.

Just to note here that Celegence has great IEC 62304 gap analysis tools. So contact us if you would like any assistance with that.