In this series, I am going to take you through a simple medical device development example where we generate documentation along the way. We are going to start with the development of user needs, break these down into requirements, design the architecture, look at risk management and analysis, as well as developing and executing verification and validation test cases.
In order to get the most out of this example, it is important to note the following:
- This example is specifically aimed at startups and small companies, but could be applied to some degree to larger companies too.
- This example is designed to meet the requirements of ISO 13485:2016, ISO 14971:2019, IEC 62304:2006/AMD 1:2015, IEC 60601-1:2005/AMD 2:2020, the FDA’s Title 12 of the Code of Federal Regulations Part 820 and the EU’s Regulation (EU) 2017/745 Article 10(9).
- It is not a comprehensive example, so while the examples contained within may meet regulations there are still many other regulation and standards requirements that are not covered.
- There are many, many ways to implement design and development, requirements, risks, etc., and this example will only touch on one possible way. You could use this as a means of inspiration and then adjust any aspects you want to meet the requirements for your device and organization.
User Needs Documentation
The first document that is created during development is the User Needs document. This document captures how users need to use the product for its intended purpose and use. These needs should be developed with each user in mind, i.e. the results should come from the users themselves in order for this document to be effective. A product may have many types of users, for example a product intended to be used on patients in a hospital setting may have various kinds of clinicians as operators, but also those who clean the device, transport the device around the hospital, or those that prepare the device for use.
Some organizations also find that the user needs may also be a place to capture the needs of other business stakeholders such as marketing, sales, distribution, etc. Others prefer to capture these in a separate document. Both are also used as input into the architecture and requirements documents. Our example will capture both business and user needs in the User Needs document.
How to write a User Needs document will be covered in Part 2 of this series.
Requirements Documentation
The requirements document forms the input into the design and development process. It captures the specific and measurable goals that the design has to meet. Requirements should be written in such a way that they do not constrain the developer to a particular design (there are some exceptions to this) but are clearly defined and measurable such that any design that meets the requirements is acceptable. Getting the level of specificity and detail correct is difficult, but an important investment of resources in a project.
Requirements can be hierarchical, and the number of levels should be commensurate with the complexity of the device. A very simple device such as gauze may only require one level of requirements, whereas an ultrasound device may require many. In the above diagram we have used system requirements, then broken these down to subsystem requirements, and then broken these down to component requirements. Some components in our example may require further breaking down into smaller and smaller components until we land at the smallest useful unit to define.
How to write a Requirements document will be covered in Part 3 of this series.
Architecture Documentation
As with requirements, the architecture is also hierarchical such that there is a traceable link between the system, subsystem, or component architecture and their set of corresponding requirements. The architecture is created to meet the requirements for that level. The architecture is then broken down another layer using the next level of requirements. As each stage progresses, the architecture becomes more detailed.
To capture the architecture, you are free to determine whether you want to document the entire architecture in one document, or create separate documents for each level in the hierarchy, or even break up the architecture document in other ways. In our example, we will break up the architecture document so that each level has its own document.
How to write an Architecture document will be covered in Part 4 of this series.
Risks Documentation
The identification and analysis of risks for your device should happen at every level of your requirements and architecture. It is important to realize that a design decision on any level (for example, architectural decisions) may introduce new risks, affect existing risks or may be used to mitigate existing risks. These risks are then compiled and analyzed in a Risk Matrix document. From here, they can also be frequently reviewed during other phases such as during implementation or testing.
To illustrate why risks should be addressed at each level, consider that if the software architecture is developed for use in the cloud, this could introduce cybersecurity risks. Then, as the architecture is broken down into smaller and smaller units, risks such as deadlocks or race conditions become an issue.
To mitigate risks, it is useful to create risk control requirements. For example, a risk where a user is unable to login because they have forgotten their password may require a requirement that the software provide password reset functionality. By creating corresponding requirements for risk mitigations, we can then ensure that this information is fed into the design and development implementation as well as trace this to verification or validation testing.
How to develop a Risk Matrix will be covered in Part 5 of this series.
Implementation
Implementation is about the design and development of solutions according to the architecture and requirements.
Verification Documentation
Verification is the process of checking that the output meets the required input. More specifically it is checking that what is design and developed (design and development output) meets the requirements (design and development input). This is usually confirmed through the collection of objective evidence.
Verification can be in the form of many different kinds of activities including inspections, walkthroughs, checklists, test cases, and analysis. However, in most cases the activities can be simplified to a set of the following steps:
- Setup the verification environment
- Follow the verification method
- Make observations and compare these observations to expected outcome
- Collect objective evidence of the results
Because this set of steps can be applied to a range of different verification techniques, we will simplify our processes by capturing all kinds of verification activities in test cases where the above steps are captured. We will also ensure that all requirements are linked to at least one test case to ensure good coverage.
Verification: Are we building the product right? – Barry W. Boehm
How to develop and execute Verification Testing will be covered in Part 6 of this series.
Validation Documentation
Validation isn’t quite the same as verification. Where verification checks the outputs meets the inputs, it doesn’t actually make any conclusions about whether or not these inputs are in fact the right ones. Validation is about looking at the higher level picture and checks what was developed conforms to the user needs and the intended use of the device, and can consistently do so. Therefore, validation should take place in expected conditions. Some validation activities include transport and packaging validation, sterilization or reprocessing validation, usability validation, biocompatibility validation, user acceptance testing, etc.
Validation may overlap with verification, and therefore test cases may be designed to support the provision of objective evidence for both activities. For example, you may design a test case where a mock user is to carry out a series of steps to meet a user need during normal operation and use to help support validation. Then at points along the way, requirements could be tested by checking the expected outcome against the actual outcome and collecting objective evidence.
Validation: Are we building the right product? – Barry W. Boehm
How to develop and execute Validation Testing will be covered in Part 7 of this series.
