An EDMS is typically used to store the following information units:
The documents themselves are stored either in read-only storage areas (storage systems with so-called soft WORM  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)
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.
 WORM = write once read many
This text is an excerpt from the GMP Compliance Adviser, Chapter 1.H.2
d.velop Life Sciences GmbH, Gescher