Table of Contents
Why User Needs?
So, what are ‘User and Business Needs’ and why do we need them?
Medical devices, at a fundamental level, need to be safe and effective. More specifically, they need to be safe and effective when used in the context of their intended use. Users play a pivotal role in the outcome of a medical device and whether or not a medical device can be deemed safe and effective when used in the context of their intended use.
Regulatory markets around the world have recognized that ensuring that manufacturers consider users throughout design and development is critical to the success of a device and the safety of patients. This principal is captured in their respective regulations and more and more focus has been placed on the usability of devices.
U.S. Market
If you are heading into the U.S. market, it is pretty clear from Title 21 of the Code of Federal Regulations Part 820 that user needs is a required deliverable.
“(c) Design input. Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. The procedures shall include a mechanism for addressing incomplete, ambiguous, or conflicting requirements. The design input requirements shall be documented and shall be reviewed and approved by a designated individual(s). The approval, including the date and signature of the individual(s) approving the requirements, shall be documented.” – Sec. 820.30 Design controls.
“(g) Design validation. Each manufacturer shall establish and maintain procedures for validating the device design. Design validation shall be performed under defined operating conditions on initial production units, lots, or batches, or their equivalents. Design validation shall ensure that devices conform to defined user needs and intended uses and shall include testing of production units under actual or simulated use conditions. Design validation shall include software validation and risk analysis, where appropriate. The results of the design validation, including identification of the design, method(s), the date, and the individual(s) performing the validation, shall be documented in the DHF.” – Sec. 820.30 Design controls.
European Market
The European market has a more indirect requirement for user needs in the 2017/745 Medical Device Regulations:
“The quality management system shall address at least the following aspects: ….
(g) product realisation, including planning, design, development, production and service provision;” – Article 10 – General obligations of manufacturers – Clause 9
“For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.” – Annex I – Chapter II – Clause 17.2.
However, as a large proportion of manufacturers choose to use harmonized standards to meet the requirements of the regulations, it is more important to check these standards.
International Standards
International standards such as the ISO 13485, IEC 62304, IEC 60601-1, etc. all mention the need to capture user goals and needs. The following examples are taken from the ISO 13485 as it is the most used by manufacturers of all international standards (please note, the standard uses the word ‘customer’):
“Top management shall ensure that customer requirements and applicable regulatory requirements are determined and met.”- EN ISO 13485: 2016 – Chapter 5.2
“Determination of requirements related to product
The organization shall determine:
a) requirements specified by the customer, including the requirements for delivery and post-delivery activities;
b) requirements not stated by the customer but necessary for specified or intended use, as known;” – EN ISO 13485: 2016 – Chapter 7.2.1
For the simplicity of the rest of the article the word ‘user’ will be used, but this will refer to users, customers and business stakeholders.
Identifying all User Personas
When you think of how your device is used, you not only have to consider those that may administer your product, but also all of the possible users in all contexts. For example, devices used in a hospital setting may pass through many different hands: such as the people that sterilize or reprocess the device for use, those that need to prepare the device for use (assembly etc.) and those that then use the device on the patient. You might also have to consider your distributors and how they transport and store your devices before delivering them to customers or end-users. It is also important to identify business stakeholders as these may also have important needs of the product that fit into their product strategy. Some of these groups may overlap, or they may have entirely different characteristics.
When identifying users, it is useful to consider their experience, limitations and the environment in which they will be using it. If you have one large group of users (for example all adults), considering splitting them up in order to capture the range of different characteristics that each group may have. Adults of 65 may have very different characteristics to those between 18-25. Chronic patients may also have different characteristics to those that suffer only occasional problems.
Name
Give your persona a name. This name will be later used in the documentation as a cross reference to clearly indicate which user persona is being considered.
Age Range
Age of users may have an impact on many difference aspects of design for your device. For example, if you have a user persona that is elderly, you may have consider aspects in design such as the readability of interfaces and instructions. If a user is very young, they may be quite adept at software user interfaces, but not so good at reading or interacting with dials or analog clock faces.
Knowledge and Experience
This could include things such as knowledge and experience using similar devices, knowledge and experience with treating this particular ailment, and/or knowledge and experience about this particular ailment. Some devices will have personas that will have totally different knowledge and experience. A blood pressure monitor designed for at-home use may have users that need to monitory their blood pressure all of the time, and others that may only need to monitor their blood pressure in rare circumstances.
Functional Abilities
What is the user able to do, and what are they not able to do? Devices intended for diabetes patients also need to consider that some of their patients may suffer from diabetic retinopathy and their vision may be compromised. Interfaces that contain information or instructions therefore may need to be design to consider different levels of abilities.
Mental and Emotional State
Consider a persona that has severe allergies. If they begin to experiencing symptoms of anaphylaxis, they may start to panic or become very stressed. They may need to be able to administer epinephrine medication in this state and their ability to do that may be heavily impacted by the complexity of the device. Therefore, you should consider the mental and emotional condition of your personas when they are needing administer the device.
Use environment
A device that needs to be used in an ambulance may need to be designed in a completely different way to a device that can be used at home. The environment in which the user will use the device needs to be considered for each persona.
User interface aptitude
If you are incorporating software, you should spend some time considering the best approach to the user interface as this will be one of the most important aspects of your device. Consider your persona’s aptitude with user interfaces, their previous experience and their expectations. For example, younger age groups might expect zooming functions to work the way they do in smartphones, however older generations might be more comfortable using dials or sliders to zoom.
Example Persona for a Surgical Ultrasound Device
| Persona | |
| Name | Surgeon |
| Age Range | >25 years |
| Knowledge and experience |
|
| Functional Abilities |
|
| Mental and Emotional Condition |
|
| Use Environment |
|
| User interface aptitude |
|
Eliciting User Needs
To design and develop a medical device, it is paramount that you have access to actual users. Preferably at least one user per user persona captured above. This means actual users, and not people who might be able represent users. It might be tempting to use a software developer that has spent years developing a particular software medical device as a user, but it is not the same as an actual user.
Also, it is also important that your decision to use a particular user to represent a persona has sound reasoning. If you are working with a training hospital and need to get your hands on clinicians, you may find many medical students or early residents that have more time on their hands. If experience and technique do not play a large role in the use of the medical device, and the medical students and residents are likely to use the device, then it may be acceptable to use them for your users. However, where experience plays a role in the way the device will be used, then it really is better to get input from an experienced clinician as well. Make sure you document your justification for your selection of users.
Once you have your users, there are different ways you can elicit their needs. For example:
- Interviews
- Checklists
- Surveys
- Focus groups
- Fast prototyping
- etc..
Depending on who your users are and your resources, you may have a particular affinity for one or more of the above options. For small companies, and companies that have difficult access to users (i.e. if you need to access hospital staff that are only available for very short periods of time in the week), it may be advantageous to go the interview route. The other advantage of interviews is that you have the opportunity to clarify with the user their meaning, ask pertinent follow up questions and even get them to demonstrate how they currently perform certain tasks.
A possible outline for an interview protocol could be as follows:
- Persona – The persona to which the interview applies
- User Description – The user selected for the interview and why. This could also include the persona table (as demonstrated in the above section), but this time with the concrete information pertaining to this user.
- Current Treatment – How does the user currently performs the task without the medical device?
- Other Treatments – If there are medical devices that can be used to perform the task, what is the user’s experience with these?
- Pain points – What are the current user’s pain points with the way that the task is performed?
- Goals – What does the user want to achieve with a new device? What are the most important things, nice-to-haves?
- Safety – Are there any safety considerations? (Any other devices that this device must co-ordinate with, any particular environmental considerations such as sterile zones or humidity, etc.)
- References – Are there any devices (unrelated to this task) that the user likes using particularly, and why? Is there any inspiration that can be taken from these devices? (Likes the workflow, likes how it can be used with one hand, likes how it is easy to assemble, etc.)
- Other Notes – Anything else the user may say that might be important to consider. Sometimes users say things like ‘When I first began as a surgeon, I was not very adept at reading ultrasound images. This is something I learnt on the job’. These sorts of things may impact your ideas about your persona or your medical device that may need addressing!
Modelling User Needs
After the information has been gathered form the various user groups, it is time to start compiling this information into a set of well defined user goals. In this example, we are going to first shape our user stories to get the first full high level view of what we need to build, and then we are going to break this down into use cases. Depending on your needs, you may decide to skip either one of these steps and simply use only the user stories as the user needs, or the use cases as the user needs. It really depends on the complexity of your device, and how well either of these fit into your design and development process.
User Stories
User stories capture the high level goals that a user is trying to achieve. In our example, we are using the user stories as a way to interpret the content that we captured during elicitation and organise in such a way that we can better break it down later to create more detail in use cases. By doing this exercise, we can see how the needs of different personas overlap and can consolidate this information. It also provides a useful way to check for completeness and coverage.
A typical user story is in the following form:
As a [persona], I can [capability] so that [benefit(s)]
If more than one persona has the same goal, consider consolidating them into one:
As a [persona 1], a [persona 2], or a [persona 3], I can [capability] so that [benefit(s)]
If the benefit differs between the personas, you could split them into two separate statements. Make sure that the two statements are kept together in the document so that there is no risk of accidentally duplicating a capability because it will be listed twice.
Here are some examples for an ultrasound device:
[US0001] As a surgeon, I want to compare a current patient image with an image taken previously so that I can see if there have been any changes
[US0002] As a surgeon I want to freeze the image view so that I can analyze the image without needing to hold my hand completely still
Where USXXXX is a unique identifier to identity the user story.
Use Cases
Once you have created your user stories, you should then use this document to start creating the more detailed use cases.
To do this, it is often useful to break down the user stories into little user flows.
[US0001] As a surgeon, I want to compare a current patient image with an image taken previously so that I can see if there have been any changes
- Show current patient image (freeze)
- List patient images (based on search criteria)
- Compare two images (based on images selected)
[US0002] As a surgeon I want to freeze the image view so that I can analyze the image without needing to hold my hand completely still
- Show current patient image (freeze)
Now we can make diagrams of what we just created:
| Use Case | Show current patient image |
| Persona | Surgeon |
| User Story/ies | US0001, US0002 |
| Preconditions | The ultrasound is currently sending a stream of images |
| Triggers | A user requests a freeze of the current image |
| Basic flow | 1. As the user is moving around the ultrasound probe, the ultrasound probe is sending a stream of images to the screen that show the current slice live 2. The user sends a freeze request and the current image is frozen and no more images are streamed to the screen |
| Alternative flow | No alternative flow identified |
| Post Conditions | No post conditions identified |
| Use Case | List patient images |
| Persona | Surgeon |
| User Story/ies | US0001 |
| Preconditions | There are a list of patient images saved to the ultrasound device |
| Triggers | A user sends search criteria |
| Basic flow |
|
| Alternative flow | No alternative flow identified |
| Post Conditions | No post conditions identified |
| Use Case | Compare two images |
| Persona | Surgeon |
| User Story/ies | US0001 |
| Preconditions | There is one patient image selected already and the system is displaying a list of patient images to select |
| Triggers | A user selects a second patient image |
| Basic flow |
|
| Alternative flow | No alternative flow identified |
| Post Conditions | No post conditions identified |
Documentation
How should all this be documented? Well, at the most basic you will need to formally create a User and Business Needs document. This could be a list of the User Stories or a list of the Use Cases, or both, that is signed and dated by relevant parties. Some general hints about documentation:- Don’t repeat yourself – If the information is contained somewhere else, make a reference to this document rather than copy and paste the content. It is better to have a system where documents can be easily retrieved for this purpose than to have to correct lots and lots of documents if a change is made. Plus, there is a quality risk if a document fails to be updated due to a change and people receive the obsolete information.
- Formalize important documents, but not others – In this case, the output document is the User and Business Needs document, so this should be documented in the SOP as a required output. Other documentation, such as interview forms or checklists, that were used to build the document may not need to be formalized, but should definitely be signed and filed anyway. When the next person is updating or continuing development of your user needs, they may need to discover how certain user stories or use case were arrived at and this may require the supporting documentation such as the interview notes. However, if you force every kind of document to be created each time you make a change to the user needs, you may force extra unnecessary work. Make your SOP flexible and document different elicitation techniques that could be used if found necessary and then create some templates that could be used, but refrain from making them mandatory.
- Purpose – a short description of the purpose of this document. This is aimed at people searching for information so that they can quickly see whether this document will contain the information that they need.
- Scope – this explains what is in scope for this document. This is also aimed at those looking to see whether this document contains the information they need.
- Responsibilities – if the responsibilities for the creation of this document differs from the SOP or template (i.e. the responsibilities are documented elsewhere), then a list of who (functions or people) are responsible for what in the document.
- Document History – a history of the versions and changes the document has undergone to get to this point. It’s like a ledge of changes.
- Introduction – if information is needed to interpret how this document is read or understood, place this information in the introduction.
- Content – the list of the user stories, the use cases or sections for both
- References – references to the template and version used (if used), references to the SOP used to create the document, etc.
