GxP-oriented laboratories are expected to comply with specific guidelines that require all testing and manufacturing processes to be performed, monitored, recorded, and reported in an organized and controlled manner. These guidelines are intended to ensure data integrity, product quality, and safety.

The best way to ensure data integrity is following the ALCOA+ principles:

Labguru has various features that help laboratories meet these principles.

When creating a record, generating or collecting data, the identity of the person who generated the data must be documented along with the date of the action.

Labguru captures every action executed by the user such as marking experiment steps as completed, adding attachments, signing protocols/experiments, commenting, and more, so that each activity can be attributable to the person who performed it.

Ensuring data is legible has more to it than just being able to clearly read the data, it must be possible for data to be read and understood years after it’s recorded, even decades in some situations. Data must not only exist, it must be also accessible.
​

Labguru stores the uploaded data on a primary database server with multiple active clusters for higher availability and the database is being backed up on a daily basis.
Data is kept and is available for export in both human-readable and electronic forms, and includes all uploaded files in their original formats: PDF files representing the text entered into the system (ELN section) and CSV of all tabular data (inventory, collections, etc).
All records are retained in the system and Labguru has a continuously tested data recovery methodology that ensures quick and optimal data retrieval in a crisis scenario.

Recording data at the time it takes place along with ensuring data is chronological, i.e. has a date and time stamp that is in the expected sequence, are important aspects for assuring integrity and reliability of results
Labguru allows you to mark steps in your experiments as “Completed” as you move through your experiments. Each step you mark as “Completed” will also be time-stamped to let you know exactly when it was done (like every other action in the system).

Records should be original rather than copies or transcriptions since it may result errors therefore, the original recording of the data should be on the main record.
Since Labguru is accessible from any device, it is simple and easy to document all your data in the system at the time it is generated rather than writing on paper and copying into the system, which may result in errors.

Labguru keeps your original data safe by employing multiple layers of protection (Firewalls, traffic monitoring measures, and additional technologies) to always limit access to approved networks and users.
In addition, Labguru is a Closed System as it requires a unique username and password to login. A strict password policy is applied to ensure it is not easy to gain unauthorised access therefore, users are required to change password every 3 months and are locked out of the system after 5 failed password attempts.
To enable further access control, users have the option to enable Two-Factor Authentication (2FA) login and user access can be also integrated with existing Single Sign-On (SSO) systems.
​

To allow further control and limit access to records, specific visibility and editing permissions in the ELN module can be granted to users according to their roles, as well as different permission levels in the inventory and equipment modules, to ensure the information is accessible only to the relevant members.

There should be no editing of the original information which might result loss of information.

If changes are necessary, it must be documented in a way that makes it possible to refer back to the original information and nothing should be removed or deleted.

Labguru is designed to assure the accuracy of your data by locking approved experiments, protocols, and documents to prevent unreliable data insertion or deletion. This permanent lock of experiments/protocols is time-stamped and possible once the experiment/protocol is signed and witnessed. The first signature is performed by the experiment/protocol owner, and the witnessing (second signature) by a user with witnessing privileges (such as the PI, head of the lab, etc.).
Witnessing will lock the experiment/protocol permanently without a reverting option.
Locking your protocols is a good way to easily track any changes in experiments generated form these protocols by comparing the experiment with the protocol it originated from.
​
Moreover, when a change must be applied to a permanently locked experiment/protocol, Labguru offers the option of duplicating the document. Once duplicated the system creates a link between the copied record and the original one so you can always go back to the original record.
You can also use the comment box, which can be found at the bottom of each protocol/experiment, to document the reason for change as these comments are permanent and cannot be deleted therefore, will be always be visible.

Labguru also has a validated version, to make all data recording and generation fall under the scope of regulatory compliance. For more information on our validation methodology click here.
​

All recorded data requires an audit trail to show nothing has been deleted or lost.

Labguru captures every single action performed in the system and records it in the audit trail which cannot be disabled. The Audit trail page, centralizes all actions performed in the system with the following information:

The audit trail can be sorted by user and by date to easily find the actions you wish to audit and exported in PDF format.

Another function that allows you to monitor data changes is the ‘Version history’ feature. Labguru saves a copy of your work every time a change is made to experiments, protocols, and documents. All versions are available in PDF format and appear in a list that can be sorted by date or member.

Protocol Versioning is also possible in Labguru. Whenever the current version of your protocol is outdated and needs to be updated, simply duplicate it, make the required changes, sign and witness to prevent any further changes and archive the previous version to have it removed from the active protocols list and avoid inadvertent use of outdated protocol.

​