Everything in one system, and the proof behind it

One system for the whole device lifecycle

Records in one stage link to records in the next, so a complaint can lead to a CAPA, a risk file and a design change without leaving the system.

Design and development

Design controls, traceability, requirements, configuration and release management

Risk

Risk management files, hazard analysis, risk-based change assessment

Documents and records

Document control, e-signatures, templates, record linking in both directions

Production and batch

Production and batch records, nonconformances, traceability by lot

Suppliers

Supplier qualification, evaluations, supplier corrective actions

Calibration and equipment

Equipment register, calibration schedules and records

Complaints and vigilance

Complaint handling, incident reporting, field safety actions

Clinical and post-market

Clinical evaluation, PMS and PMCF plans and reports, periodic safety reports

CAPA and audits

CAPA, internal and supplier audits, management review

Training

Training records, competence, read-and-understood tracking

EU AI Act

12 record-keeping modules for AI-enabled devices (outside the scope of our validation guide)

Notified-body workspace

Audit programmes, findings and certificates for a designated notified body, under revocable consent (pilot)

Browse all 130+ modules

Reliability evidence

• 18,000+ automated tests

  Automated tests run on the whole product before every release, including tests against a real PostgreSQL database that check one company can never read another's data.

  How we know: Full run before the 31 Oct 2026 releases: more than 18,000 tests passed and 15 failed. The 15 are older known failures tracked as a baseline; the release gate requires zero new failures against that baseline.

• 227 tables

  Separation between companies is enforced by the database itself (forced row-level security), on top of company filters in the application code.

  How we know: Counted in the production database on 31 Oct 2026 (tables with forced row-level security). A guardrail test fails the build if a new company table is added without a policy.

• Hash-chained audit trail

  Every create, update and delete is logged with who, what, when and before/after values. Each entry carries a SHA-256 hash linked to the previous one, so altering or deleting an entry is detectable.

  How we know: The chain starts at a documented cut-over, so earlier entries are not chained. Entries written directly by a data-correction script sit outside the chain and are reported as unchained. Details on the Compliance page.

• E-signatures

  Each signature records the user, time, meaning, reason and IP address, and asks for the password again. Approved records are locked.

  How we know: Older signatures from before our content-hash change carry no content hash; this is an open item we track and publish on the Compliance page.

• 130+ modules

  One system and one login for the lifecycle above, instead of several tools to connect.

  How we know: Counted from the module registry in the product code; the Modules page lists each one.

• Published prices

  Plan and bundle prices are on the pricing page, without a sales call.

  How we know: See the Pricing page; the comparison page shows which vendors publish prices, with sources.

Security and data separation

• Each company's data is separated in the database with forced row-level security, plus a company filter on every query.
• Hosted in Hetzner's Helsinki data centre (Finland, EU). TLS 1.2+, TOTP multi-factor authentication, passwords hashed with PBKDF2-HMAC-SHA512 (210,000 iterations).
• Database backups every 6 hours, encrypted and kept off-site.
• We do not claim database-level encryption at rest today. Read the full list, including what is pending, on the Security page.

How a change reaches production

1. 1. Review

   Every change is read by a panel of reviewers (security and tenant isolation, regulatory, database, interface, correctness) and, for regulated behaviour, by an independent regulatory reviewer. Changes touching signatures, security or the database go to a human first.

2. 2. Test

   The full automated suite runs. A change that adds a failure against the known baseline does not ship.

3. 3. Gate

   A pre-deploy gate checks the build, database migrations and guardrails. Production never migrates itself: it refuses to start with a pending migration, so schema changes are applied and checked first.

4. 4. Roll back

   If the health or public check fails after a release, the previous version is restored automatically.

5. 5. Watch

   Health monitoring raises alerts, including for a company with no recent backup. Backups are encrypted, kept off-site, and an automated restore check runs weekly.