Document release - is the four-eyes principle necessary?

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.

1. What do we mean by document release?

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)

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:

For example, the release of a software requirements specification can be permission to proceed to the creation of the software architecture.

2. Why are efficient document releases important?

Unnecessary waiting

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.

Lack of “quality gates”

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.

QM bureaucracy

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.

Regulatory risks

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.

3. Regulatory requirements for the document release

a) ISO 13485:2016

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.

b) IEC 62304

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:

• Software requirements in section 5.2.6
• Software architecture in section 5.3.6
• Detailed design in section 5.4.4
• Software units in section 5.5.2 et seq.
• Software (as a whole) in section 5.8

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:

• Chapter 4.3 “Generation and Control of Documentation”: “Documents containing instructions should be approved, signed and dated by appropriate and authorized persons.”
• Chapter 2.5 “Head of Production” and Chapter 2.6 “Head of Quality Control” specify the responsibilities of the key personnel: “Approval of instructions … and other procedures [for quality control].

d) FDA

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)

4. Is the four-eyes principle required?

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.

5. How to tell if your document release processes are efficient

If you want to know whether your processes are being slowed down by inefficient releases, check the following aspects:

• Do you demand as many signatures as possible? The more, the “better”.
• Have you made sure that all top-level managers and directors have to sign?
• Have you made sure that these people are often unavailable and, ideally, rarely on site? Making sure that there aren’t any regulations on alternate signatories would be another "tip".
• Do releases have to be done on paper in a circulation procedure? Several locations would be perfect.
• Do you define a repeated release as not reaching a milestone that has already been reached?
• Do you let the QM or Regulatory Affairs departments decide on technical contents?
• Do you use document management tools that are as unpopular as possible because, for example, no one can use them or they are often not available and because it is still necessary to print and sign the documents by hand even when they are used?

Does that sound cynical? How many of these points apply to you?

This is the reality that the Johner Institute often sees.

6. How to make your document release processes efficient

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.

a) Involve the right people

Document release

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.

Document review

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:

• The author or the person responsible for the activity/phase. For software architecture, that would be the software architect.
• The purchaser of this phase or document. For software architecture, this is the person who wrote the system specification, for example a product manager.
• The contractor for this phase or document. To stick with our software architecture example, this would be the developers who have to implement this architecture.
• The person responsible for the tests who can check that what has been written can also be tested. For a software architecture, this would be the integration tester, if there is one.

Special case: quality management

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:

1. Plans: Development plan, software development plan, risk management plan, etc.
2. Process-related releases, e.g. software release according to IEC 62304 section 5.8
3. Process and work instructions

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.

Special case: risk management

Risk managers can be involved, but do not have to be. It depends on the project or product.

Conclusion

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.

b) Use tools and aids

Reduce the barriers for document review and document approval with simple tools.

Checklists and 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.

Binary test criteria

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.

Compact documents

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.

Images and models

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.

c) Separate the review and release as well as the product and process aspects

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).

e) Select the right set-up

The document review and the document release are activities that require a lot of concentration. Pay attention to the following:

• Individually instead of (only) as a team
  Do the initial review individually, not in large team meetings. At the meetings, you can collect the results from the individual reviews, compare them and come to a final decision.
• Regular short reviews
  Prioritize regular, timely and short reviews (< 30 minutes). Most brains are tired after 45 minutes of intensive reviewing.
• Work undisturbed
  Create places where you can work in peace or get together as a team. There must be no telephone and email disruptions.

f) Create a supportive culture

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.

7. Conclusion

Inefficient processes due to inefficient reviews and releases

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:

1. You still have to work with the documents.
2. You lose the benefit of a thorough review and release in the sense of a “quality gate”.
3. You are exposing yourself to regulatory risks.

Four-eyes principle

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.

Support

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.