There are several critical changes that need to be analyzed for their potential impact on your devices and the processes required to submit them for CE marking, and it’s important to make two critical determinations for your software. If the answer to either question is yes, then the medical devices regulation (MDR) or in-vitro devices regulation (IVDR) may have several new requirements for you to implement before placing your device on the market in the EU.

The first determination to make with your regulatory experts is this: Does it meet the new criteria to be considered Medical Device Software (MDSW)? While this remains a challenging undertaking, luckily the European Commission’s Medical Devices Coordination Group (MDCG) has issued guidance on this matter that may prove helpful. It is not legally binding, of course, but there is a high likelihood that notified bodies and competent authorities will follow most or all this guidance when determining the characterization and classification of your software and/or device.

The guidance defines MDSW as follows: “Medical device software is 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 medical devices regulation or in vitro diagnostic medical devices regulation.” Further clarification is then provided: “…not all software used within healthcare is qualified as a medical device. For example, “Simple search”, which refers to the retrieval of records by matching record metadata against record search criteria or to the retrieval of information does not qualify as medical device software (e.g. library functions). However, software which is intended to process, analyze, create, or modify medical information may be qualified as a medical device software if the creation or modification of that information is governed by a medical intended purpose.”

This definition holds true if the software has dual or even multiple uses. For instance, if the software drives or influences a (hardware) medical device and has a medical purpose, it is viewed as being MDSW. The MDCG provides a decision tree to assist in determining if your software is MDSW and provides several examples that you can review with your regulatory partner. It is important to note that if your software is determined to be MDSW, it may require its own classification if it operates separately from a device for a medical purpose, or has medical purpose features and functions which are independent of the device that it controls or with which it interacts.

Further, the documentation requirements for a device to be CE marked may apply equally to the MDSW, especially in terms of verification and validation and could necessitate the inclusion of documentation which indicates the components, algorithms and technologies applied in its creation and use.

Depending on the use scenario(s) and packaging, the MDSW may also be subject to creation of a separate Unique Device Identification (UDI). The type of interoperability or connection between the MDSW and the device, whether embedded or wireless etc., is not determinant under MDR and IVDR as to MDSW status. The MDSW may be placed on the market in one of two ways. It can be placed as a medical device or in-vitro diagnostic medical device unto itself, or it may be placed as an integrated component of a hardware device.

If you have determined your software is not a medical device as defined by the new regulations, it is important to make a second determination with your regulatory partner: Should your software be considered an instruction for use? Instructions for use (IFU) can be broadly defined as technical documentation supplied by the device manufacturer and provided to users of the device. The IFU may include information on product safety and provide guidance on proper installation, test and calibration, operation, and maintenance of the device. If your software provides any of this information to the end user, it may be considered part of the IFU and could be subject to the expanded labeling requirements of either MDR or IVDR, which both place a much higher emphasis on intelligibility of the instructions and other documentation.

For instance, MDR states that “The medium, format, content, legibility, and location of the label and instructions for use shall be appropriate to the particular device, its intended purpose and the technical knowledge, experience, education or training of the intended user(s). In particular, instructions for use shall be written in terms readily understood by the intended user and, where appropriate, supplemented with drawings and diagrams.” IVDR contains similar language to this effect.

It is also important to understand that, up to now, many medical device manufacturers have only translated software when it was required by an EU member state, often leaving a large disparity between translated IFUs and device software.

This was acceptable, in part, because both MDD and IVD were directives, which allowed differing interpretation and implementation by Member States. But MDR and IVDR are regulations that, under EU law, require uniform implementation by all Member States and may change this common translation practice dramatically. MDR and IVDR both require that to place a device on the EU market, the information to be supplied with the device (e.g. label and IFU) must be provided in the official language(s) determined by the member states. In addition, a device manufacturer must maintain all instructions for use, in every language version, on the company website.

In light of this, it seems prudent to re-evaluate the architecture and customer-facing content of your software and its appropriateness as defined by the new regulation, as several additional questions are raised:

• Have you placed sufficient emphasis on internationalization to accommodate the unique localization requirements of the member states?
• If your software is considered to contain IFU information, does it meet MDR or IVDR requirements for clarity?
• Can it be easily located for each required language and region on your company website?
• Does your software authoring include consistent terminology creation? Concordance is more important than ever between the device onscreen information and the IFU. Again, MDR and IVDR require that you must be consistent and clear in your communication.
• Is your software translated into all member state languages where it is to be placed on the market?
• If you lack adequate funding or human resources to “simship” to every member state while meeting these new requirements, will your software architecture support single language release so a phased approach can be followed?
• Is your documentation and staffing sufficient for the new requirements including EUDAMED upload?
• Does your software need to be released in tandem with your IFU based on its status and classification now that you must upload all your relevant documentation to EUDAMED?
• Are any of these new requirements built into your budget, schedule, hiring or overall product launch planning?

It cannot be emphasized enough that you should engage regulatory experts to answer many of these important questions and to make the final determinations regarding the status and classification of your software. Their answers can have a massive impact on your entire organization and ultimately decide the success or failure of your efforts.

Want to know more?

• mdreurope.com
• ivdreurope.com
• MDCG Software Guidance