Menu
Menu
This article covers the typical document deliverables that you will have in a medical device product development project. Bear in mind that this is merely a simplified overview to help you understand the flow of information and the logic behind the process, as well as that different companies may have different approaches and use different terminology.
In the video below, this topic is expanded, as it is a part of our online course on Design Control for medical devices.
The basis for this document overview is an electric instrument which includes embedded software and a sterile single-use device or disposable. Some documents in this overview might in reality have two documents of the same type – one document for the instrument, and another similar document for the single-use device, but for the sake of simplicity, there are no duplicates in the video overview.
Even though other areas are mentioned, the focus here is related to design. Other areas are covered in greater detail in our other courses on risk management, medical device software development, safety for electrical medical devices, and project management courses.
The starting point of the development is some kind of product idea or business opportunity that an organization would want to exploit; moving over to the end, and the goal, it would be to release the product to market. This can be done with or without clinical investigations, depending on the type of product and what data are already available.
One of the first things to do, when developing a new medical device would be to understand the intended use. This would answer questions like who will be using the product on whom for what, when, and where. This is obviously closely connected to the product idea and business opportunity that was mentioned before. The intended use represents a reasonable starting point not only for medical devices, but any product development project.
Speaking of a starting point, a project charter or project brief for a medical device is a common way of documenting a formal start of a project. The project charter will authorize the project manager to initiate the planning of the project.
When the intended use has been established, the manufacturer should be able to determine the needs of future users. The user needs must be documented, and a common place to do that is in a requirement traceability matrix. When the user needs are known, then they can be translated to design input (technical requirements) that will make sure the product satisfies the user needs.
Not only user needs must be documented, but the design inputs should be documented, and this can also be done in the requirement traceability matrix. In reality, this is a highly iterative process. In addition to this, it is important to remember that many processes take place at the same time.
Collecting user needs is closely related to the usability engineering process. The usability engineering process will also require a use specification. It is a more granular version of the intended purpose and use and contains details about the users and patients. The use specification will feed information into both the preliminary hazard analysis, as well as the task analysis.
At the stage of defining user needs and design inputs, which is part of scoping a project, the regulatory strategy should be completed. The regulatory strategy will be impacted a lot by the intended use, and also to some extent the claims that are planned to be made for the medical device. These two factors could make a world of difference in terms of what market access routes are open to the manufacturer.
While the design and development inputs, or user needs and design inputs are being defined, design control requirements start applying to the work, which means that the project manager should be busy planning the project and creating a design and development plan (DDP), or project plan.
Next, based on the regulatory strategy, norms and standards that will apply to the product should be defined. This is where many start-ups will fail, because they are either not aware, or are reluctant to start working with regulatory questions for various reasons. In a large company, this is most likely done by someone in the QA or RA departments and the name of that document would be something like “applicable standard and norms list” or “standard search report”. Since the standards will contain requirements that will have an impact on the product, the applicable requirements from the standards should be found in the requirement traceability matrix.
When sufficient design inputs have been defined, the manufacturer can start designing the system. This may or may still not be the detailed design, but rather the high-level architecture of the product. For a product that is not complex, this architecture will be simple, but if it is, as in this case, an instrument with software and maybe a disposable sensor, the architecture becomes really important, both for the success of the product in general, but also in terms of safety of the system.
As there is software in this example product, someone would be starting to draft a software development plan as well, but planning must take place in other areas as well, for example risk management planning. And having a risk management plan is required by the ISO 14971 standard.
To avoid writing requirements that can’t be verified, it is strongly recommended to start defining how to verify and validate the requirements already when they are being defined. Putting a short text in the requirement traceability matrix and how it is going to be handled is critical in helping the requirements authors understand if the requirement makes sense. When that has been done, or in parallel, planning the verification and validation of the product on a high level should be done – in fact, it is a requirement to plan them, according to ISO 13485.
Apart from planning design and development, verification and validation, a third area is specifically required to be planned, and that is the design transfer. This is not too surprising since setting up a production capacity and translating the design into manufacturing specifications should be an integral part of any product development project.
When it is roughly known what the system design or architecture is going to be like, and the risk management work has started, the software safety classification can be performed. Records of the results of the classification should be created. If the software comes out with a higher classification than wanted or expected, it might be needed to go back and iterate both on system design and software architecture. If you want to learn more about software safety classification or any other area relating to software in this overview, register for the online medical device software development course.
The next step would be to start breaking down system requirements from the requirement traceability matrix into subsystem requirements, and the one area where this is required is when the system contains software.
Lastly, it is time for a detailed design. To create the outputs of the detailed design, the manufacturer would work on the mechanical design, including packaging and the disposable kit that is part of the example product, design electronic schematics and create Gerber files, create assembly drawings and the labelling (both labels on the product and packaging, as well as the instructions for use). The source code for the software is also output from the design effort. All the outputs should be maintained using document control.
The manufacturer can, and has to continue working on risk management, documenting both the risks, as well as the risk controls identified in the hazard traceability matrix or risk assessment and control table. The software will eventually be more and more complete, and it can be created incrementally through multiple sprints. Everything that is being developed needs to have documentation, particularly when and if it is software in software safety classifications B and C.
In parallel with designing the product, more detailed verification protocols can be created to prove that what has been designed meets the design inputs. It is likely to have close to a hundred protocols (as opposed to several shown in the video above).
One area which deserves a course on its own is electrical safety testing. It is more than that because it is everything relating to the 60601-1 standard, which applies to the example medical device. This testing can be both expensive and very time-consuming if not done right. If you need to learn more about this area, do take a look at the online course on safety for electrical medical devices on our website.
As the protocols become ready, or even during the process of verifying requirements, the requirement traceability matrix should be updated again with references to the protocols and records.
Get instant access to our online Design Control for Medical Devices course right here. In 6 hours, you can learn more about how to develop new medical devices and maintain them in organisations where design control requirements apply. This course is taken by quality assurance, project management, design engineering or those involved in R&D and product development teams.
Or if you’re looking for a tailored training to align with your company’s specific needs – contact us for inhouse training options.
Peter Sebelius is a highly esteemed trainer, consultant and entrepreneur in the medical device industry. He is a member of the Joint Working Group that is revising the ISO 13485 and ISO 14971 standards.
He has vast ‘hands on’ experience, having developed, amongst other things, a mechanical chest compression device and an ex vivo perfusion machine for lungs. He has received numerous awards including the Great Design Award and the title “This year’s specialist” by Veckans affärer.
Receive FREE templates and quarterly updates on upcoming courses that can help you in your career! Subscribe to our newsletter now.
When you submit this form, you will be sending personal information to medicaldevicehq.com. To comply with GDPR requirements, we need your consent to store and use the personal data you submit. Take a look at our Privacy policy for more details.
