Document control is a documented procedure that specifies how documents are created, reviewed, approved, labeled, distributed, and updated.
Organizations certified according to ISO 9001 or ISO 13485 are obliged to document control.
1. Subject matter of document control
It is obvious that document control is about documents. What is less obvious is what documents are.
Some understand documents to be the superset of
- specification documents (e.g., standard operating procedures, work instructions, templates, checklists, forms) and
- records (e.g., measurement logs, completed checklists, and forms).
In some cases, “specification documents” and “documents” are used synonymously, contributing to confusion.
It is, therefore, helpful to refer to the surplus of specification documents and records as “documented information,” as ISO 9001 does from version 2015 onwards. It no longer distinguishes between specification documents and records in document control (in contrast to other standards such as ISO 13485).
2. Objective of document control
For auditors, the following applies: What is not documented does not exist. Accordingly, documents and records are also crucial in the audit.
What is meant by document control is made more apparent by the term “control of document”: The objective of document control is to ensure that
- the right (correct, complete) information is provided
- at the right time
- to the right addressees
This, in turn, requires that
- no invalid, incorrect, or incomplete information is distributed,
- invalid information is withdrawn,
- it is clear who needs to receive this information,
- information is given about new, changed, or deleted documents to these persons, and
- it is ensured that this information is understandable to these persons.
3. Regulatory requirements for document control
The aspects just mentioned can be found in standards such as ISO 13485. They require that you define (and document, of course :-)) how to
- evaluate documents before distributing them,
- update and approve documents,
- ensure that changes are identifiable,
- ensure that documents are available (and remain readable),
- ensure that old versions are not circulating, and
- determine the length of time documents will be retained for (although there are specific minimum requirements).
ISO 13485 does not address the “release” of documents but their “approval.”
Read the article on document approval (German) for an even more detailed overview of the regulatory requirements.
This article gives tips on how you can quickly review and release your documents.
Another article describes the requirements and use of electronic documents and electronic signatures. (German)
4. Typical problems: What often goes wrong in the audit
In audits, manufacturers and auditors regularly encounter similar problems:
- The documents or information are unknown. Try asking an employee on the line what the quality policy is…
- There is an outdated work instruction at the workplace.
- During internal audits the document control was not reviewed.
- It is not clear which device or software version documents refer to.
- There are no updated documents for a device or software version.
- The development documents, such as the development plan, were released long after the development had started.
- The standard operating procedure does not specify how long which document types are to be retained and how, or it ignores legal requirements.
- There is a lack of defined review criteria for evaluating the various document types. A signature alone is not sufficient.
- For some documents in the file system or SharePoint their status (e.g., draft, approved, withdrawn) is not visible.
- There are several files of the same name but with different contents in the file system.
- Manufacturers cannot explain if and how they provided training on documents such as work instructions or standard operating procedures or why it was unnecessary.
- Modified specification documents were not re-trained.
The Johner Institute regularly experiences audits that involve document control, resulting in deviations. These complaints are not an expression of excessive formalism but mostly of chaos on the part of the medical device manufacturer, which is not limited to the documents.
Our e-learning platform will give you the necessary knowledge and experience to build a compliant quality management system. Avoid typical mistakes when creating your processes and benefit from our insights from hundreds of QM audits. Our hands-on learning content allows you to tailor your knowledge to your business and needs.
5. Ways to control documents
5.1 Overview
There are numerous technical options available to manufacturers to control their documents. These include
- File system, network drives
You should clearly regulate the read and write permissions and ensure everyone has access. This is a particular issue in production. - Cloud storage
Your employees can easily access documents with services such as Dropbox or Google Drive and their mobile clients. However, restricting read or write permissions does not always work. - Document management systems
Applications such as Microsoft Sharepoint (also available as a cloud service) or document control software (e.g., roXtra or PTC) simplify versioning and allow the definition of document workflows for creating, reviewing, approving, publishing, and withdrawing documents. The difficulties can be found mainly in the details, in setting up, and configuring the tools and training them. - Wiki -> PDF
Some companies work with wiki systems like Confluence and either benefit from plug-ins for release (electronic signature) or export the documents to PDF. I.e., they use the wiki “only” as an editor. The tools of our sister company, Medsoto, such as the MedPack and the DocuPack, even save printing. - Version management systems
Companies that work close to development usually already use version management systems like SVN or Git. However, these systems are more suitable for purely textual documents, e.g., in Markdown. Usability is often an issue for technophobes. On the other hand, features like branching, tagging, commit comments, and integration into build tools open new possibilities. More about this is described in the next chapter.
5.2 Example: Document control (for technically advanced users only)
5.2.1 Procedure
Technically advanced users can use a combination of the tools Git, Pandoc, and Jenkins. With this tool chain, one can achieve the following workflow:
- Document in Markdown
The author creates a document in Markdown. It is a very simple text-based language that is easy to learn. For example, a text is underlined with equal signs (“=======”) to mark it as a heading. These texts are very readable and are also displayed as nicely formatted web pages in systems like Github. - Storage of the documents in Git (with appropriate branches)
The author commits his changes or his new document to a development branch. Once released, the changes are “merged” to the master branch. When we work on customer documents, we create our own branches. - Creating Word documents
Since many people prefer to work with Word: Each commit triggers a build process that automatically generates the Word documents. These Word documents are automatically versioned during the build and stored in the version control system (Git). - Working with Word documents
Optionally, users can synchronize these documents with their computers.
You can also skip the generation of Word documents.
5.2.2 Evaluation
Advantages
- Clear, transparent workflow
- Easy tracking of changes via the Git onboard resources (with Word, this is only possible via the comparison function, which is more time-consuming)
- Uniform document layout (by adjusting the template, all documents get a corresponding layout)
- Work with multiple versions in parallel: Improvements made for a customer can be easily merged back into our master branch.
- The documents are available to the users in the familiar Word format.
- Conversion to PDF, LaTeX, HTML, etc., is “built in.”
Disadvantages
- The system of Git, Pandoc, and Jenkins (including build script) must be set up and a corresponding tool landscape must be maintained.
- Creating and modifying documents requires more than just Word skills.
- The Markdown language allows only limited layout customization (although even text alignments in tables, lists within lists, footers, etc. are possible).
6. Outlook
Many organizations still understand document control and the requirements for it very literally, namely as the control of documents on paper or as files, e.g., as PDFs. Most authorities and notified bodies require such documents.
However, document-oriented approaches are a concept of the past. Modern companies are switching from document-driven processes to data-driven processes. This enables them to achieve
- higher compliance (e.g., through automated reviews),
- reduced workload (e.g., by automating the creation and review of content),
- faster time-to-market, and therefore also
- greater competitiveness.
However, the normative requirements for document control remain, such as transparency regarding the (release) status of information or protection against information loss.
The Johner Institute supports manufacturers of medical devices and IVD medical devices in their digital transformation, e.g., as part of the Fit for Future Program. This involves manufacturers converting their documents into structured data.
7. Summary
Organizations have little chance of successfully passing an audit without precise document control. Not only do they create unnecessary regulatory risks, but they also increase the likelihood that their devices and services will be non-compliant and put patients at risk.
A carefully compiled toolchain helps to minimize the “overhead” of document control. You can ensure that the right people have the right information at the right time and that they understand it.
The future of document control is the control of structured information rather than documents. Manufacturers should prepare for this and drive their own digital transformation.
Change history
- 2024-07-29: Link to the revised article on electronic signatures inserted in Chapter 3.
- 2024-05-02: Introduction text changed, 1st chapter inserted, other chapters renumbered, Fig. 2 redesigned, 5th chapter structure adjusted, 6th chapter and last sentence inserted
- 2019-03-20: First version created