21 CFR Part 11 · Regulated Instrument Workflows

Tamper-evident audit capture for instruments that only write files.

GIMS Compliance Relay converts raw instrument data creation into append-only compliance records in an HMAC-keyed hash chain, attributed to a server-resolved user, timestamp, device, and project. Records are reviewable and signable in-app and export as sealed evidence an auditor can verify offline, all without changing the instrument workflow.

See how it works
What the relay captures
  • Who generated the raw data file, resolved server-side (never accepted from the network)
  • When it was created and from which workstation
  • Which project and folder path were involved
  • Tamper evidence via an HMAC-keyed hash chain, externally notarized (object-lock WORM in the self-hosted or AWS stack; filesystem notary locally)
  • Reviewed, approved, or rejected e-signatures bound to the exact records
  • Sealed CSV and JSON exports an auditor can verify offline
Primary use case NMR and other file-writing instruments in regulated environments
Deployment model Local (SQLite + filesystem, no DB or cloud needed), self-hosted Postgres + MinIO, or AWS. Edge capture or central server-of-record.
The problem

Many instruments create electronic records without creating defensible audit trails.

When a valuable instrument would improve a production or QC workflow but its native data environment falls short of regulated data-integrity expectations, the burden typically falls back onto paper logs, spreadsheets, or manual re-entry, each of which introduces transcription risk and weakens the audit record.

Manual logging is fragile

Paper and spreadsheets do not natively bind a user, timestamp, device, and primary data file together in a tamper-evident way. The record and the file are not connected.

Re-entry creates risk

Every time an analyst transcribes or manually attaches information into another system, the record can drift from the original file event, introducing error without surfacing it.

Native software may not be enough

Instrument software generates files, but may not provide the user attribution, append-only logging, and tamper evidence that regulated QA workflows require.

How it works

Capture the origin and integrity of raw instrument data, without touching the instrument workflow.

The relay runs on the instrument workstation, watches configured folders, and automatically records the compliance event the moment a file is created.

1

Instrument writes data

An NMR or other instrument writes primary data into a controlled folder on the workstation.

2

Relay watches the folder

The desktop relay runs at OS startup, detects new files, and captures the compliance event automatically.

3

Compliance record is created

The event is written to an append-only, HMAC-chained log with server-resolved attribution. Events with no resolvable actor are rejected, never recorded as "unknown".

4

Review, sign, export

Records are reviewable and signable in-app with password re-authentication, then exported as sealed CSV / JSON an auditor can verify offline.

Core value

Turn any instrument that writes files into a traceable, tamper-evident, signable data source for regulated workflows, with no changes to the instrument itself. The Part 11 hardening work is complete and exercised by 134 automated tests against a live Postgres deployment.

Why regulated teams use it

It closes the gap between useful instruments and acceptable records.

  • Keyed hash chain plus external notarization. Each record's HMAC-SHA256 checksum covers the prior record, so any edit, reorder, or insertion breaks verification; trail heads are anchored to an external notary as witnessed checkpoints (object-lock WORM in the self-hosted or AWS stack; filesystem locally).
  • Non-forgeable, server-side attribution. The actor is resolved by the server from the OS session or a verified signed token, never accepted from the network. Events with no resolvable actor are rejected.
  • Real two-component e-signatures. Signing re-verifies the password even inside an active session, requires a meaning (approved, reviewed, or rejected) and a reason, and binds to records that already exist in the trail (§11.200, §11.70).
  • Deploy where the data must live. Local, self-hosted Postgres + MinIO, or AWS; capture at the edge and forward the whole signed record to a central server-of-record.
  • Integrates, does not replace. The relay is the compliance capture and integrity layer in front of LIMS, ELN, or broader GIMS workflows, not a substitute for them.

Best-fit use cases

  • NMR systems that produce valuable primary data but need stronger audit capture to meet regulated workflow requirements
  • Instrument workstations that already sit in controlled enterprise environments with individual authenticated logins
  • Labs replacing paper or spreadsheet logging for raw data creation events
  • QA teams needing exportable evidence showing when a file was created, by whom, and from which machine
Scope and boundaries

What the relay does and does not do.

The relay is designed to do one thing well: capture the origin and integrity of raw instrument data events. Review, approval, and disposition workflows remain in downstream systems.

Question Relay Handled elsewhere
Who created the raw data file, when, and from which device? Core function
Is there tamper evidence on the raw data record? HMAC-keyed hash chain + external notarization (object-lock WORM available) Enterprise storage hardening and SOPs remain necessary
Electronic signatures (reviewed, approved, or rejected)? Core function (§11.200 two-component, re-authenticated, bound to specific records)
User identity, accounts, and capture attribution Authenticated accounts, lifecycle, and lockout; server-resolved capture identity Integrates with enterprise domain login and IT access controls
Full scientific review, batch disposition, and product release Downstream, out of scope LIMS, ELN, QA systems, or broader GIMS modules
Backup, archival, and long-term retention Object-lock WORM notarization available for trail heads Customer / IT backup and retention policies remain necessary
On scope

The relay stays deliberately focused: capture, integrity, and signatures done well, without becoming a LIMS. It now provides its own authenticated accounts, electronic signatures, and external notarization, and it is provider-neutral, so it can run where your regulated data must live. It integrates with your existing LIMS, ELN, and identity controls rather than replacing them.

Implementation

Start with a single instrument workstation. Scale by project or site.

Setup is designed to be straightforward within a controlled enterprise environment. No instrument changes required.

01

Install

Deploy the desktop package on the instrument workstation or controlled PC.

02

Configure

Select the project and watched folder or folders for one or more instruments.

03

Run at startup

Set the relay to launch at OS startup so logging begins as soon as the authenticated session starts.

04

Review and export

Use the UI for project-level audit logs, filtering, and CSV / JSON exports for QA and inspection use.

Expansion path

Start as a relay. Expand when you need more.

The relay is already self-contained for capture, integrity, and signatures. When you need to grow, it grows along two axes without a rewrite: from local storage to a self-hosted or cloud server-of-record, and from single-workstation edge capture to a central ingest point. It integrates with your LIMS or ELN at the compliance-record level rather than duplicating them.

  • Local SQLite + filesystem to self-hosted Postgres + MinIO for multi-site deployments
  • Self-hosted stack to AWS (RDS Postgres, S3 Object Lock, Secrets Manager)
  • Edge capture to a central server-of-record via durable, ordered forwarding
  • Integrate with existing LIMS or ELN at the compliance-record level
  • Extend to additional instrument types beyond NMR as the installation matures