An efficient document release procedure is one of the most important prerequisites for an effective quality management system.
This article will explain how you can improve your team's productivity and increase the quality of your products and processes through an efficient document release procedure.
You will also find out whether the four-eyes principle is necessary.
ISO 9000:2015 defines documents as “information and the medium on which it is contained.” It names records and requirement documents, e.g. specifications and procedural instructions, as examples.
Documents are subject to a document life cycle (see Fig. 1)
Fig. 1: Document control: The document review and the document release are parts of the document life cycle
The document review should ensure that the document conforms with the requirements established previously. These requirements come, for example, from standards or your own specifications, such as process or work instructions.
In contrast, the document release is the permission to move on to the next stage. ISO 9000:2015 also defines it in this way:
“Permission to proceed to the next stage of a process or to the next process”
Source: ISO 9000:2015
For example, the release of a software requirements specification can be permission to proceed to the creation of the software architecture.
Inefficient document releases can shut down your entire team: it has to wait for overworked experts and supervisors to review and release the documents. The project stagnates.
Worse still: the team does not wait and simply continues working (e.g. developing) without the review and release step. The documentation has lost its function as a quality assurance element.
The creation of the documents is then rightly perceived as a process that is as time-consuming as it is pointless; as an excess of QM bureaucracy.
If manufacturers do not review or release documents (or do not do so at the right time), they fail to comply with the regulatory requirements. There is a very real risk that this will be a problem during an audit or approval process.
The consequences are time-consuming and costly fixes, delayed approvals or even legal problems.
ISO 13485:2016 does not mention the term release, even when talking about document control. However, in section 4.2.4 on document control, it requires documents to be both evaluated and approved. This approval corresponds to or leads to the release.
In section 7.3.4, the standard explicitly requires the approval of the development results before the release of the product and, in section 7.3.5, it requires the evaluation of the development results.
Section 5.5.1 is relevant with regard to the four-eyes principle:
“Senior management must document the interrelationships between all people who direct, perform and evaluate work that affects quality and must ensure the necessary independence and authority to perform these duties.”
ISO 13485:2015. Section 5.5.1
This means that a person cannot check their own work.
IEC 62304 does not use the term release with regard to documents, but with regard to software. However, the standard explicitly requires manufacturers to specify the following in their development plan:
“For each identified document [...] procedures and responsibilities for development, inspection, approval and amendment [...] must be referenced.”
DIN EN ISO 62304:2016 section 5.1.8
The approval corresponds to the release. IEC 62304 describes the criteria to be used to review (not release) the documents in the following sections:
c) EU GMP
The EU's Good Manufacturing Practice (GMP) guidelines are really aimed at manufacturers of medicinal products and not manufacturers of medical devices. Nevertheless, they represent the state of the art.
For example, in Chapter 4 of this guideline the EU requires:
The FDA documents its document control requirements in 21 CFR part 820.40:
“Document approval and distribution. Each manufacturer shall designate an individual(s) to review for adequacy and approve prior to issuance all documents established to meet the requirements of this part. The approval, including the date and signature of the individual(s) approving the document, shall be documented.”
FDA: 21 CFR Part 820.40
In 21 CFR part 211,194, the FDA states:
“(8) The initials or signature of a second person showing that the original records have been reviewed for accuracy, completeness, and compliance with established standards.”
FDA; 21 CFR part 211.194
This is where the four-eyes principle requirement is established. Strictly speaking, it is not intended for medical device manufacturers. However, 21 CFR part 820.20(1) is relevant for medical device manufacturers:
“Responsibility and authority. Each manufacturer shall establish the appropriate responsibility, authority, and interrelation of all personnel who manage, perform, and assess work affecting quality, and provide the independence and authority necessary to perform these tasks.”
FDA: 21 CR part 820.20(1)
Although no regulatory requirement uses the term four-eyes principle, it is clear that at least two people (four eyes) are required to write, review and release a document.
However, there is no requirement for several people to review the document, nor do the regulations prevent one person from performing the document review and document release steps.
However, if the aim of the release is to evaluate the correctness, existence and completeness of the review, the reviewer and “releaser” cannot be sufficiently independent if they are the same person.
If you want to know whether your processes are being slowed down by inefficient releases, check the following aspects:
Does that sound cynical? How many of these points apply to you?
This is the reality that the Johner Institute often sees.
The design of the document release process depends on the size of the team, its distribution, how the company is organized, the type of device, etc. However, the following best practices help regardless of these factors.
The release gives people the permission to move onto the next process step. This release can be issued by a person or a role, for example, the process owner (e.g., development manager), a project leader, or a regulatory affairs or quality manager familiar with the process or project.
You only need one person. A four-eyes principle is neither required nor sensible. If there is only one role, that role is responsible. There's no danger of anyone relying on anyone else.
The situation is different with the preceding document review. You need more than one person for such reviews.
But even here you should keep the number of people as low as possible. As a general rule, only the following should be involved for development projects:
Quality managers have a special role to play: Like the senior management, they do not have to be involved much in the release of the product requirements and specifications.
However, if the documents have a process aspect, you should involve the quality managers in the review. This applies in particular to:
Testers are often organizationally assigned to quality management. In that case, the quality management is indirectly involved according to the above tips.
There is another instrument for quality management to review process compliance: the design review.
Risk managers can be involved, but do not have to be. It depends on the project or product.
No more than four or five people should be involved in a review. So it's more like an eight-eyes principle :-).
In your SOP, you can also specify that whether the document is a new document or a revised document affects which people are involved.
Any role that cannot make a contribution but which makes scheduling more difficult should be removed from the review.
Reduce the barriers for document review and document approval with simple tools.
Use checklists with a maximum length of both sides of one sheet of paper. Use either an ALM tool (e.g., MedPack or JIRA) or paper.
Everybody should have these checklists printed and stored in a folder or drawer within arm’s reach. This way you can immediately begin the review and/or the document release.
Web-based ALM tools are better for teams that are spread across different locations in particular.
Whether on paper or in the tool: only include concrete and verifiable points in the checklists. A question like “is the document complete?” is pretty pointless.
In contrast, a question like “is there a two-column table at the end of the document in which the left column lists all system requirement IDs and the right column contains a keyword or a half-sentence regarding implementation in the architecture?” can be checked precisely.
Avoid monster documents. Take the documents apart! A system architecture must describe the system components (e.g., programmable electronic subsystems (PESSs)) and their interaction. The PESS requirements, however, can be formulated for each PESS. The same applies for the system architecture.
The smaller a document, the quicker and easier it is to review. If possible, you should avoid documents that have multiple roles.
You should also avoid long document headers. All cross-sectional aspects such as glossaries should be “factored out”. They make the documents more difficult to review and release.
Avoid long continuous text in the documents to be reviewed and released. Images, tables and models are more compact and can be reviewed more quickly and more easily.
Separate reviews and releases. The review is about checking that the contents are complete, correct and comprehensible.
The release is generally about project management and process compliance.
Both activities require different test criteria. Different roles are responsible for the two activities (see above).
The document review and the document release are activities that require a lot of concentration. Pay attention to the following:
Express your appreciation for these review activities as a manager or project manager. If you think that only a programming programmer is a good developer, you are in the wrong job.
Incidentally, Google rates reviews just as highly as document writing and programming.
Inefficient document releases shut down your entire team. Inefficient processes are usually the result of the document review and release not being regulated in the best possible way.
Not releasing documents (in good time) is not wise:
Do not confuse the document review with the document release. Several people should be involved in a review. Here, the four-eyes principle can be helpful, but is not mandatory. However, this is not the case with the document release.
If the purpose of the release is check the evaluation, the releaser and evaluator cannot be the same person. So, the four-eyes principle is de facto mandatory, even if the regulations do not use this term.
The creator and reviewer of a document must never be the same person. A four-eyes principle is indispensable here.
Do you have the feeling that your processes and document reviews and releases are not efficient enough? Does your team shy away from these activities meaning they get pushed back? Then get in touch with us. We will be happy to help you streamline your processes to enable you to develop your products more safely and to market them faster.