Medical device manufacturers are obliged to both describe the development process and create a development plan. Because both documents specify how medical devices will be developed, there is uncertainty as to which information belongs in which document.
This article resolves this and also examines the software. It looks at the software development plan and the description of the software development process, which is often referred to as the “Software Development SOP” or “Software Development Standard Operating Procedure.”
The standard operating procedure for development (description of the development process) should contain all specifications that apply to the development of all devices.
The development plan, on the other hand, contains all the specifications specific to developing a particular device.
If the manufacturer is only developing one device, it is possible to combine both documents. Otherwise, further factors must be taken into account, as presented in this article.
1. Description of the development process
There are several largely synonymous terms for “process description.” In the case of the development process, these are
- description of the development process
- standard operating procedure development
- development SOP
a) Contents
A procedure or process description should be defined in general terms, i.e., independently of a specific device or project, who carries out which activity when and how, with which input, and which output.
| aspect | description | example |
| what | activities that must be carried out | The system architecture of the device must be designed, documented, and verified. |
| when | determination of the sequential and/or parallel order of activities. This also includes determining whether development can or must be iterative. | The system architecture must be verified immediately after it has been finalized. |
| who | accountability roles | The Head of Systems Engineering is responsible for the verification of the system architecture. |
| how | methods and tools with which the activities are to be carried out | Verification must be carried out using checklist 23B in the ALM tool, and the results must be documented there. |
| inputs | inputs for the process or the activities | The inputs for the development are the system requirements. The architecture document and the checklist are the inputs for verifying the architecture. |
| output | results of the process or activities | The process results in a fully verified and validated device and legally compliant technical documentation. The result of the verification is a completed checklist in the ALM tool. |
These aspects are reminiscent of the turtle diagram, which is a simple model for creating procedure and process descriptions.
To delve deeper into the topic, the following information is available:
- keyword “processes and procedures”
- standard operating procedures
- development process
- agile software development
- development according to the V-model
b) Development process: documentation
The documentation, i.e., the process or process description, usually contains the following:
- A cover sheet with information on document control and notes on the scope of the application
- A process overview, for example, in the form of a flow chart (e.g., UML activity diagram)
- A description of the phases, which group one or more activities
- For each phase and/or activity, the responsible roles, the expected inputs, the methods, the tools and the outputs to be generated
Verification activities are also planned.
Please note that the development process should require creating a development plan.
In the Medical Device University, you will find templates for a development process and a development plan.
c) Regulatory requirements
MDR/IVDR
MDR and IVDR oblige manufacturers to prescribe in the QM system…
product realisation, including planning, design, development, production
Article 10 MDR, IVDR
The EU regulations also require the respective annexes XI…
the procedures and techniques for monitoring, verifying, validating and controlling the design of the devices and the corresponding documentation as well as the data and records arising from those procedures and techniques.
Annex IX MDR, IVDR
ISO 13485
ISO 13485 also requires a description of the processes in addition to a development plan (see below):
The organization must plan and develop the processes necessary for product realization.
ISO 13485 Chapter 7.1
Please note that the FDA adopts the requirements of ISO 13485. This means these requirements also apply to devices marketed in the United States.
IEC 60601-1
IEC 60601-1 does not insist on a general description of the development process. For programmable electrical medical systems (PEMS), it requires “only”:
A PEMS DEVELOPMENT LIFE CYCLE must be documented.
IEC 60601-1 Chapter 14.4
This requirement can also be met by a development plan.
IEC 62304
IEC 62304 also does not insist on a general process or process description. Even the chapter “Software Development Process” “only” requires a software development plan and sets out requirements for the activities involved in software development.
2. Development plan
a) Contents
The development plan must define the specifications for a specific development project or device to be developed.
If the “development SOP” essentially regulates the procedure (i.e., makes almost all the necessary specifications), the development plan contains only aspects such as:
- Concrete definition of the deadlines or assignment of the deadlines to the milestones defined in the development process
- Assignment of persons to the roles required by the description of the development process
- Changes to the specifications of the development process (if the process allows for a degree of freedom)
- Other specifications that the process description allows or requires. For example, the content of checklists for the code review may depend on the programming language chosen for the respective development project.
b) Documentation
The development plan can thus be condensed into a two-page document. This consists, for example, of:
- cover sheet with
- references to the device (e.g., UDI-DI)
- elements for document control (e.g., version, author)
- reference to the development process
- tables with assignments, e.g., of persons to roles
- short sections with additions
c) Regulatory requirements
MDR, IVDR
MDR and IVDR do not have any specific requirements for development plans.
ISO 13485
The quality management standard requires a development plan. The content of this plan is defined in Chapter 7.3.2, “Development planning.”
This includes the development phases. This means that the description of the development process (the general standard operating procedure) does not have to include these specifications or that the development plan may override these specifications.
IEC 60601-1
IEC 60601-1 does not distinguish between standard operating procedures and the development plan. However, it requires specific development phases, such as specification of requirements and architecture.
Use the V model as the documentation model for compliance with IEC 60601-1 requirements.
IEC 62304
IEC 62304 requires that the development plan address the aspects mentioned in the chapter “Development Process.” It is common practice to reference the development process. In particular, the software development plan should include:
- The specific process (the standard allows free choice; however, the process must be defined.)
- The inputs and outputs of the activities, including formal requirements for documentation
- Tracing, testing, configuration management, and problem-solving must be explicitly addressed.
- The objective of the specific development project (a reference to software requirements)
- Tools
- Standards and/or your own specifications, such as coding guideline
The development plan should be available first. However, this means that tools and specifications for testing have already been designated. This is not always sensible. For example, it is the task of the Software Architect to select technologies, such as a programming language, that are suitable for compliance with the software requirements. Depending on the choice of programming language – to continue the example – the choice of
- the tools,
- the test methods, and
- how the configuration management is implemented.
Therefore, adjusting the development plan during the development process is often necessary, which is not a problem from a regulatory perspective.
3. Decision criteria for the distribution between the development plan and development process
a) Degrees of freedom
You can choose whether you would rather document your requirements in the description of the development process or in the development plan (see Fig. 2).
The development plan would be written in the first case, which essentially only references the development SOP. In the second case, the development SOP states that the details will be defined in the development plan.
b) Decision criteria
When deciding how to divide the content between the two documents, you can be guided by the type and size of your organization (see Tab. 2).
| type of organization | recommended allocation |
| development service provider | You work on many different projects and devices. This requires other technologies and specifications from the manufacturers. In this case, you will document most of the specific content in the development plan. |
| small company placing only one device or a few very similar devices on the market | Your process models for the individual devices differ slightly, and you can already include most of the content in your SOP. |
| medium to large medical device manufacturer | You develop many devices using different technologies and software systems; a standard SOP that applies to all of them can only be a general one. The details are regulated by the respective development plans. |
Discover how you can make your development process audit-proof while continuing to work efficiently. Benefit from our Medical Device University to get your medical device to market quickly while meeting all the relevant requirements.
4. Conclusion and summary
Manufacturers have a great deal of leeway when deciding
- how to divide the content between the standard operating procedure for development (description of the development process) and the development plan,
- which process models to choose.
However, this leeway should not obscure that standards and laws strictly regulate what manufacturers must define. Regardless of which document.
Do you have questions about the development plan or the development process? Are you unsure whether your specifications meet the legal and normative requirements? Or do you feel that your templates only create bureaucratic “overhead?”
Get in touch. We will help you ensure that your audits and approvals go smoothly and without unnecessary effort and that your devices reach the market quickly.
Change history:
