30.10.2018 | LOGFILE Feature 42/2018

An excerpt from the GMP Compliance AdviserChapter 1.H.2

The Structure of Electronic Document Management and Quality Management Systems (EDMS/EQMS)

5 min. reading time | by Thilo Gukelberger


An EDMS is typically used to store the following information units:

  • The document itself (e.g. MS Word, Excel, PDF files)
  • Document attributes or metadata (e.g. title, SOP number, author, batch number, subject)
  • Relationships between users and documents (rights, roles, organisational hierarchy)

The documents themselves are stored either in read-only storage areas (storage systems with so-called soft WORM [1] functionality) as files or else in a relational (SQL) database or as so-called BLOBs (binary large objects).

If both the documents and their attributes/metadata are saved in a file-oriented filing system (soft WORM functionality), the overall system becomes more flexible, especially with large amounts of data, but care must be taken to ensure that the documents and attributes are saved consistently. Particularly during data backup, the documents and their attributes must have the same status. Therefore, the respective vendor guidelines (backup manual) must be carefully adhered to.

The use of attributes and/or metadata allows for the automated grouping or bundling of documents that are related in terms of content. This is also referred to as the creation of files or dossiers. The attributes and metadata are almost always stored in a database (usually a relational SQL database).

Electronic batch records are a good example of an application of the bundling of documents. If the batch number is regarded as the common attribute that is identical for all documents of a batch record (e.g. production record, analytical testing record, packaging record), an EDMS can automatically insert each document of the manufacturing process into the correct batch file in the electronic record.

In this example, the process of inserting a document into a file and/or dossier should not be envisioned as it is with paper-based documentation. Paper documents can only ever be stored in one physical location. If the document is required in physically different places, it must either be transported manually or copied. Both alternatives have major disadvantages. Manual transport involves the risk of documents being lost, but in any case time is lost; a paper copy involves the risk of inconsistencies between the original and copies. Therefore, an EDMS usually only stores a single instance of a document and presents it to various users simultaneously in different process contexts.

The work processes utilized in conjunction with an EDMS/EQMS are typically organised as shown below in Figure 1.


Figure 1 Work processes employed together with an EDMS or EQMS (schematic)

  1. Start: The user starts his EDMS/EQMS application. This may either be in the form of a native client application or an internet browser may be used.
  2. Authentication: The user provides his authentication in the EDMS/EQMS. If mechanisms such as "single sign on" are used here, the user is already automatically authenticated by logging on to the company network. In the GxP environment, however, the user has to authenticate himself again at the latest when he performs his electronic signature.
  3. Search: The user searches for documents. To perform this, the user enters search criteria in the system’s user interface which are sent to the EDMS/EQMS server.
  4. Authorisation: The EDMS/EQMS server provides a suitable hit list depending on the access rights of the logged on user. Initially, this only consists of the metadata of the delivered documents.
  5. Function: The user now selects the desired match and determines – usually via the context menu of his user interface – which function he wants to execute with the selected document (e.g. "display document", "revise document", "check document").
  6. Authorisation: The EDMS/EQMS server determines if the user possesses the necessary rights and performs the requested action with the document as appropriate.

When selecting a suitable EDMS/EQMS, it must be ensured that the authorization checks mentioned above are always carried out, regardless of the interface that the user uses to communicate with the EDMS/EQMS.

An EDMS that is also used outside the GxP area usually contains functions that are not GxP compliant. If, in this case, one has add-on modules that ensure the proper handling of GxP relevant documents, it must be ensured that these documents are only made accessible by means of these add-on modules. Figure 2 shows functions that are essential in the GMP environment, but are often missing in EDMS systems:


Figure 2 Additional requirements in the GMP environment

Apart from the functional scope of an EDMS/EQMS software solution, it must of course be validatable. This requires in-depth knowledge of the system architecture and system functions. Ideally, the supplier will provide a pre-validated system so that the effort required for project-specific validation can be minimized. A pre-validated system should include the documents for the DQ, IQ, OQ, at a minimum, if necessary as templates, which are then adapted to the specific project.

[1] WORM = write once read many

This text is an excerpt from the GMP Compliance Adviser, Chapter 1.H.2

Thilo Gukelberger


Thilo Gukelberger
Business IT Specialist, Managing director of the Life Sciences division of d.velop Life Science GmbH
E-Mail: thilo.gukelberger@dvelop-ls.de