In today's article, we will discuss IEC 62366 in medical software. What will you learn? We will answer questions such as what IEC 62366 is, what the usability engineering process is, and what distinguishes formative and summative evaluation. Let’s get started.

What is IEC 62366?

IEC 62366 is an international standard that “specifies a process for a manufacturer to analyse, specify, develop and evaluate the usability of a medical device as it relates to safety”.

This standard is divided into two parts:

• IEC 62366-1 – the first document depicts the application of a usability engineering to medical devices,

• IEC 62366-2 – the second part is a guidance on the application of usability engineering to medical devices.

So, what is IEC 62366 about? Simply put, it’s about assessing the risks associated with using a medical device (user interface). Some might occur when a medical device is used properly, but some users might use the device incorrectly, leading to potentially dangerous situations for users’ health.

IEC 62366 applies to all medical devices, including medical device software (MDSW)  which we will focus on in today's article. It is worth remembering that MDSW consists of SaMD (Software as a Medical Device) and SiMD (Software in a Medical Device).

Is IEC 62366 harmonised with MDR?

You might wonder if IEC 62366 is harmonised with the MDR (Medical Device Regulation). The short answer is no, it’s not. 

However, the past version of this standard (IEC 62366:2007) was harmonised with the MDD (Medical Device Directive). Both documents have been replaced with newer regulations (MDD with MDR and IEC 62366:2007 with IEC 62366:2015).

MDR and IEC 62366:2015 are not harmonised, yet in the MDR, we can find information that the manufacturer should follow the “state of the art” when developing the medical device software. Thus, the MDR suggests that when working on the MDSW, you should follow the guidelines set in both parts of IEC 62366.

IEC 62366 and FDA

The other question you might have is – whether the IEC 62366 is recognised by the U.S. Food and Drug Administration (FDA)?

The FDA recognises the IEC 62366 and has also developed their own guidance on usability engineering, which you can find here. While there are overlaps between the two, if you're considering introducing your medical device software to the U.S. market, it's crucial to follow the FDA's instructions, which we strongly encourage you to read.

What is usability engineering in medical device software?

Before we describe the guidelines set in IEC 62366, we should define some key terms from this standard. The first of them is usability engineering.

Usability engineering is also called human factors engineering. What does it mean? It’s an “application of knowledge about human behaviour, abilities, limitations, and other characteristics to the design of medical devices, system and task to achieve adequate usability” (source: IEC 62366).

To put things simply, it means that the product (in that case, MDSW) should be intuitive and safe to use, taking into consideration how people act when using medical devices. Does it sound familiar? Well, IEC 62366 is closely related to the positive user experience.

To better understand usability engineering, let’s talk about normal and abnormal use.

What is normal use and abnormal use?

There are two main categories of usage when using a medical device software: normal and abnormal. What are they, and how do they differ?

Normal use in IEC 62366

Normal use means using a medical device in a generally accepted way despite there being or no instruction for use.

Normal use can be split into two categories:

• correct use – which stands for using a MDSW properly, without any errors,

• use error – which describes a situation in which an action or lack of action “leads to a different result than that intended by the manufacturer or expected by the user” (source: IEC 62366).

Use errors are usually unintentional, as they can be related to poorly visible information on the screen, omitting a task because one does not remember it, or using a wrong component. You can find more examples of use errors in Annex D of IEC 62366.

Abnormal use in IEC 62366

On the other hand, abnormal use is an “intentional act or intentional omission of an act that is counter to or violates normal use”. It can be divided into a few categories:

• exceptional violation,

• conscious disregard for the contradictions,

• reckless use,

• sabotage (source: IEC 62366).

Sounds complicated? Think about abnormal use as going against the intended use stated by the manufacturer of the medical device software, i.e., using it the wrong way despite the knowledge that their actions aren’t correct. 

To understand it better, let’s consider an example – imagine that a medical app is used by people who weren’t specified by the manufacturer because a child lied and declared being above 18 years old.

What is a usability engineering process?

Now that we know what usability engineering is and how to distinguish normal use from abnormal use of your medical device software, we can focus on the usability engineering process.

So, the aim of the engineering process is to provide safety to the user of the medical device software. Ensuring this safety should consider elements such as:

• transport

• storage

• installation

• operation 

• maintenance and repair

• disposal (source: IEC 62366).

The usability engineering process according to 62366-1 consists of nine steps (chapters 5.1-5.9), of which crucial parts we will discuss below.

Bear in mind that the information, records, and documents you will gather during this process constitute a so-called usability engineering file. This file (or rather set of files) will be used to check the compliance of your medical device with IEC 62366.

Prepare use specification

The first step of usability engineering according to IEC 62366 is to prepare the use specification. What is the use specification? 

Well, it's a document that includes all the information about the users of your medical software. This is similar to the intended purpose description, but is more extensive and focuses more on the user's characteristics. The discussed standard lists such issues as:

• intended medical indication (what will your medical device be used for?, which illness or condition will it help with?, what are the contraindications for its use?), 

• intended patient population (age, state of health), 

• intended part of the body or type of tissue applied to or interacted with (if you are developing a physical medical device, for the medical apps, you will probably omit this point),

• intended user profile (consider who will use your medical device – patients or healthcare providers?, is it accessible for people with disabilities?, can children use it?), 

• use environment (where will your medical software be used – home or medical facility?, are there any specific requirements that the environment must meet, such as in terms of lighting or noise levels?),

• operating principle (main principles of the medical application's operation – will it be used on a phone or a computer?, what are the requirements for the device on which it will be used?, will it be used daily or less regularly?).

IEC 62366 in medical devices enables you to develop safe medical software for your users. However, achieving this high level of quality requires preparation of all the above information, so this first step is crucial for the usability engineering process.

Identify hazards, hazardous situations, and hazard-related use scenarios

As a manufacturer, you are obligated to identify known and foreseeable hazards and hazardous situations that could affect the MDSW's users. The guidelines outlined in IEC 62366-1 (5.2-5.5) refer to the ISO 14971 standard and its specified risk analysis. This approach facilitates the identification of potential use errors, leading to more efficient implementation of design changes in medical software.

What are those hazards and hazardous situations? Let’s define those terms:

• hazard is a potential source of harm (physical injury or damage to the health),

• hazardous situation stands for a circumstance in which people are exposed to one or more hazards,

• hazardous use scenarios demand complex, step-by-step descriptions of the situation that might happen due to the hazard and hazardous situation (source: IEC 62366-1).

Let’s consider an example of such a situation regarding medical device software, such as an app recording data from a glucometer. The glucose concentration measured by the glucometer is given in units of mg/dl, while the application’s default unit is mmol/l. In this case, the application would display a much higher blood sugar concentration than the patient actually has (90 mg/dl would be recorded as 90 mmol/l, which would be an alarming value for a healthcare provider, leading to unnecessary treatment).

Another example is a medical device software detecting heart attacks. If the algorithm fails to detect abnormal heart behaviour, the alarm indicating the need for medical assistance would not be triggered, potentially leading to the patient’s death.

Plan and conduct the user interface evaluation

Once you establish all the hazard-related scenarios, you should plan and conduct an evaluation which can be divided into two parts – formative and summative. But first, let’s talk about the user interface.

What is the user interface specification?

User interface stands for “the means by which the user and medical device interact” and the user interface specification is a document in which you state requirements which are related to the usage of the product.

The user interface specification is the result of previous usability engineering activities. As a manufacturer, you should include use specification, all the actions your user can perform when using your medical device software (including use errors and hazardous use scenarios) but also testable design requirements, e.g., a pop-up notification, visible even when using other apps on your phone. 

What’s more, this document should cover the risk control measures that you have previously identified and determine whether any accompanying documentation (operating instructions) or specific training is required.

How to plan the evaluation of your medical device software?

You have already developed the user interface specification and assessed the risks. Now it's time to plan actions to verify if everything has been detected and to correct potential errors which might occur. What are the general rules of planning the evaluations?

1. Define the goal and evaluation methods

The first step is straightforward: define what you aim to achieve through the evaluation and specify whether both (formative and summative) evaluations will be conducted. In addition, you should take into account (in the case of formative evaluation) what the tests will be conducted on, e.g. on Figma prototypes. 

2. Describe the participants of the User Tests

In the planning process for both evaluations, it's important to specify who will participate in the User Tests. Will it be a medical specialist or a typical patient? Also, take into consideration factors such as age, gender, or disabilities, if it’s stated in your use specification.

3. Determine the test environment

During the planning stage, indicate where the User Tests will take place. Will it be in a laboratory, at your company's headquarters, or will you simulate the environment, such as home or a hospital?

4. Specify knowledge of the participants

It's also important to clarify whether users will freely use the medical device software. You may want to ask them to perform specific actions or provide them with instructions beforehand.

What’s more, you might want to consider whether user training will be necessary, and if so, determine the time between training and User Tests.

Now, let’s get into planning and conducting specific types of the evaluations.

What is formative evaluation in IEC 62366 in medical devices?

To put things simply, formative evaluation aims to ensure that the medical app is safe and intuitive to use but also to identify potential user errors. 

Additionally, before starting the formative evaluation, you should identify which user interface elements will be tested. Consider that you don't need to analyse every screen of the application, only those whose clarity and safety you are uncertain about. 

Another element is scheduling the timing for conducting the evaluation. You should answer the question: at what stage of the project will it take place? It is usually conducted during the process of designing the user interface. Thanks to this, it’s easier to find potential errors and fix them before they pose a more complex problem (e.g., finding an issue after launching your solution might be dangerous).

Formative evaluation is a collaborative effort, typically involving UX (User Experience) specialists and regulatory specialists. Together, they can effectively identify and address potential errors and hazards, and develop a prevention plan to mitigate their occurrence.

The attractiveness of formative evaluation is its adaptability. You can customise the process to suit your specific needs and circumstances. How? Let's explore some options: 

• conduct a comprehensive analysis of the medical device by your UX specialist,

• involve potential users (patients or healthcare providers) who will use the mock-up,

• discuss your mock-up with experts on your team.

You can do either one of those steps or all of them – it depends on you. We recommend focusing on the formative evaluation as it allows you to guarantee the best possible user experience.

What is summative evaluation in IEC 62366 in medical devices?

Summative evaluation aims to “obtain objective evidence that the user interface can be used safely” based on the final version of your product. Why must it be the final version? Because this type of evaluation is required in order to validate your product design.

In the planning process of summative evaluation, it is crucial to specify:

• hazard-related scenarios that will be tested,

• methods of testing along with explanations of how they allow obtaining objective evidence,

• user interface elements that will be evaluated,

• criteria to determine if safety-related information (instructions, labels) is noticeable, understandable, and helpful.

How do we obtain “objective evidence”? It usually means conducting a test on a group of users (User Tests) to verify that they are using the medical device as intended. What’s more, this kind of research is usually conducted in a simulated environment.

How to achieve this? You could give your potential users access to your medical software and ask them to perform typical actions for your solution. If your regular users will use this app at home, ask them to try it out in the same environment. This way, you will gather comprehensive information about use errors.

Who should you test? In your summative evaluation, you should include people with the qualities stated in the use specification, e.g., they suffer from a disease your medical device software helps alleviate.

And how many users should you include in your tests? In IEC 62366, there is no information about the number of participants. On the other hand, the FDA demands at least 15 people. Also, if you look for information provided by other specialists, you can find that Nielsen Norman Group suggests testing with only 5 users. Their research states that this number gives the best results, if you conduct tests thrice on the same group of five people.

So, what’s the best approach? The number of participants depends on the project and the target groups of the medical device. Due to the necessity of obtaining objective evidence, the number of tested individuals should provide statistically reliable results.

What if you detect a use error during summative evaluation, the cause of which is the user interface? Then the summative evaluation becomes formative evaluation. After you do all the necessary corrections to provide users with safety, you are required to conduct the summative evaluation once again.

Those are the most crucial steps in the usability engineering process, but they are more comprehensively described in the IEC 62366. Thus, we encourage you to thoroughly read this standard to ensure you don’t skip any steps when preparing the usability engineering file.

Is IEC 62366 mandatory?

It's natural to question the need for yet another standard. However, we want to underscore the crucial role of IEC 62366 in the development of medical device software. Understanding its significance is key to ensuring the safety and usability of your products.

As we have already mentioned, IEC 62366 isn’t harmonised with MDR. However, a manufacturer should follow the “state of the art” when developing a MDSW. It suggests that meeting the requirements set in IEC 62366 will help certify your product as a medical device in the European Union.

You should remember that IEC 62366 is all about the safety of the medical software’s users. Thus, if you take your time to list all the hazard-related scenarios and conduct formative and summative evaluations, you can provide your clients with a safe, reliable, and easy-to-use app.

Not to mention, making your medical device compliant with IEC 62366 will translate into a profit. People (both patients and medical providers) will gladly use tested and safe medical devices. On the other hand, if the device lacks intuitive UX or its use leads to harm, people won’t use it, which will make you earn less money.

Following the guidelines set in IEC 62366 will benefit your medical software and its users. By complying with this standard, you will ensure that your app is easy and safe to use. And isn’t that something to strike for?

How can Revolve help you?

Now that you know what IEC 62366 is and why it is essential when developing medical software devices, what should you do next? If you are in the process of creating your medical software, let us help you.

At Revolve Healthcare, we have a group of experienced UX specialists and regulatory experts who will gladly answer all your questions. What’s more, we have worked on a medical software solution for people with diabetes in compliance with IEC 62366; thus, we can easily support you by developing a medical software that meets all the requirements.

At the core of our work is the development of medical software that is of the highest quality and safe for your users. If you would like to discuss your idea, we invite you to sign up for a free consultation with our experts.