What it looks like at work
One value, the whole path: edit check, query, correction with a reason, verification and signature. Every step lands in the value’s history.
- Checked on save725 kg is out of range — a query opens to the coordinator by itself.
- Corrected with a reasonA saved value changes only with a reason, and the reason is audited.
- SDV and signatureThe monitor verifies, the investigator signs with re-authentication.
- SystemEdit check opened a query
- A. Smirnova, coordinator725 → 72.5 · data entry typo
- I. Morozov, monitorSDV: verified against the source
- Dr Petrov, investigatorSigned with re-authentication
- 36
- URS requirements — each one has an automated test
- 1
- transaction for a change and its audit record — they cannot be split
- 0
- physical deletions of clinical data — by anyone, sponsor included
- Weekly
- restore rehearsal from backup — with a report
Source: the traceability matrix and the architecture decision log; both ship in the vendor package.
Why now: the new EAEU GCP Rules
Since 10 March 2026 the EAEU Rules of Good Clinical Practice apply in a revision aligned with ICH E6(R2). For the first time, Union rules require validation of computerised systems and ALCOA for source data.
- 03.11.2016EEC Council Decision No. 79 — EAEU GCP Rules
- 01.08.2025Decision No. 63 — the new revision
- 10.03.2026The revision enters into force
What this asks of an EDC — and how we built for it
- Validation of the computerised system
- A vendor package for every release: requirements, traceability to tests, OQ report.
- ALCOA for source data
- Author, entry time separate from the visit date, “before → after” and a reason for every change.
- Data integrity across software updates
- The schema only expands; clinical tables are protected from destructive changes.
- No exclusive sponsor control over site data
- Nobody deletes site data; a copy of a site’s data can be produced at any moment.
The whole study — in one loop
Every step is visible where it happens: the check at the field, the query at the value, the signature over a snapshot of the data.
- Screening
- Demographics
- Eligibility
- Visit 3
- Vital signs
- Adverse events
- Type
- Number, 1 decimal
- Unit
- kg
- Range
- 30–250
- Out of range
- Open a query
eCRF builder without a programmer
Visits, forms and checks are assembled in the builder and tried out in preview. A ready design can be loaded from a file as a study package.
- Weight · Visit 3Open
- Consent dateAnswered
- Heart rate · Visit 2Closed
Queries at the value, not in email
Manual and automatic in one register: who answers, by when, and the whole thread at the field.
SDV at a keystroke
The queue shows only what is not yet verified. Editing a verified value clears the mark by itself.
Signatures designed for Part 11
Re-authentication, meaning and scope, a hash of the data snapshot. Editing signed data removes the signature.
- Number
- EXP-01A16-4D63
- Cut-off
- 22.10.2026 14:00 UTC
- Downloads
- Each one audited
Data as of a cut-off date
A document numbered in the export log, with a checksum and an audit record of every download.
An audit trail that cannot be rewritten
The trail is not “kept next to” the data — it is part of the write itself. A value cannot change without a trace: not through the UI, not through the API, not from a module.
- Enforced by the database
- Database triggers forbid UPDATE, DELETE and TRUNCATE on the trail. The application’s runtime role has no right to bypass them.
- Hash chain
- Every record is chained to the previous one. Integrity is checked by recomputation — including by the recipient of the closeout package, offline and without us.
- Who, what, when and why
- Value before and after, the reason, the author’s role and organisation at the time, and the entry time kept apart from the event time.
- Dr Petrov · Signed the form
- I. Morozov · SDV: verified against the source
- A. Smirnova · Changed the value72572.5Data entry typo
- System · Opened the query “Check the weight”
ALCOA++ is the record model, not a slogan
- Attributable
- author, role and organisation on every record
- Legible
- the trail reads as sentences: before → after, reason
- Contemporaneous
- entry time is stored apart from the visit date
- Original
- a correction adds a record instead of overwriting
- Accurate
- checked against the field definition before writing
- Complete
- a change without audit fails the build’s test gate
- Consistent
- time is UTC only, ISO 8601
- Enduring
- clinical data are never physically deleted
- Available
- any field’s history — on screen and in exports
Every role has its own work
Access is computed from policies, not job titles: everyone sees their own queue and the next action.
Enrols subjects, enters data and answers queries.
- The check fires on save — the error is visible at once
- Queries arrive at the field, not by email
- Changing a saved value always requires a reason
- Answer the query “Check the weight”Awaiting reply
- Enter visit 4To enter
- DemographicsComplete
Verifies data against source documents and runs queries.
- The SDV queue shows only what is not yet verified
- A discrepancy becomes a query right at the field
- Changed-after-SDV is its own visible state, never guessed
- Vital signsChanged after SDV
- Adverse eventsAwaiting SDV
- DemographicsVerified
Builds the design, owns the rules, locks and database lock.
- A design version is reviewed and approved before publication
- An amendment moves subjects to the new version, with audit
- Locks on a form, visit, site or the whole study
- Open queries3 left
- Investigator signaturesIn progress
- SDV of critical fieldsDone
Signs the data and answers for the site at inspection.
- Sign a form or the whole casebook — with re-authentication
- See what changed after signing
- Any value’s history in one click
- Casebook RU-001-014Changed after signing
- Casebook RU-001-009Awaiting signature
- Casebook RU-001-003Signed
Performs medical review and codes terms.
- Review is its own status axis — it does not block SDV or signing
- Editing a value resets review by the system — nothing is lost
- Term coding lives in a separate queue
- Adverse eventAwaiting review
- Concomitant medicationCoding
- Medical historyReviewed
A validation package — from the vendor
The customer validates the system for their own processes. We hand over everything the vendor has for it — for every release, from the same repository as the code.
- VMPValidation planApproach, roles and acceptance criteria of the vendor’s work.
- URSRequirement catalogue36 requirements with risk and source: Part 11, Annex 11, ICH E6(R3), 152-FZ.
- RTMTraceability matrixEvery requirement → the automated tests that check it.
- OQOQ protocol and reportTest case descriptions and the full test run of the release.
- SIGSigned test runThe run manifest is signed with a key; without a valid signature the server will not publish.
- SBOMRelease compositionA CycloneDX SBOM and a vulnerability register with a rationale for every finding kept.
- JSONRestore rehearsalsA weekly restore of the backup into a scratch database — with a machine-readable report.
- VSRRelease notes and summary reportWhat changed in the release and the outcome of the vendor’s validation work.
The traceability matrix is generated from the requirement catalogue and the automated tests on every build: a requirement without a test is visible at once.
Request a sample packageYou decide where the data live
The same delivery — in the vendor cloud or in your perimeter. No “lite” editions.
Vendor cloud
Hosted in Russia and operated by us.
- Location
- Russian Federation
- Personal data
- We process on behalf of the operator (152-FZ)
- Backup
- Nightly copy, weekly restore rehearsal
- Recovery point
- Up to one day — said plainly
- Updates
- The old version serves until the new one passes its checks
Your perimeter
Installed on your side — the same releases and procedures.
- Location
- Your servers and network
- Personal data
- Never leave your perimeter
- Backup
- Procedures and checks from us, storage is yours
- Updates
- Managed releases with notes and a vendor package
- Rollback
- Code goes back in one command; the schema only expands
Modules — in the same release
Built-in vendor packages extend the core through the SDK — no core changes, the same permissions and audit. Enabled per organisation and applied to studies.
- BioequivalenceCrossover design, clinical-phase board, samples and chain of custody, PK dataset (EEC Decision No. 85).
- Lab reference rangesRanges by sex and age, LOINC, Excel import and an L/H flag next to the value on entry.
- eCRF configuration testingTest cases for every check and condition, run by the same engine, with a report for approval.
- Source document importScans, PDFs, spreadsheets: values linked to their source, a human reviews each one.
- OpenClinicaImport CRFs from OpenClinica 3.x templates and back — with a report of what the format cannot express.
- AssistantExplanations and drafts inside your perimeter. It suggests, a human decides; it cannot write data.
Moving from OpenClinica?
CRF design from OpenClinica 3.x templates becomes a regular design version: forms, groups, code lists, skip logic and checks. Whatever the format cannot express goes into a report.
Procurement questions
Short answers to what gets asked before a contract.
Did not find an answer? Write to info@x7insight.ru
Who validates the system?
The customer — for their own processes and in their own environment; the verdict is theirs. We provide the vendor package for every release: validation plan, requirement catalogue, traceability matrix, OQ protocol and report, signed test run and SBOM.
Where are the data hosted?
In the vendor cloud — in the Russian Federation; or in your perimeter, where you decide. The personal data operator is the sponsor or the site; we process on the operator’s behalf.
How do electronic signatures work?
Every signature requires re-authentication, carries the name, date-time and meaning, and is bound to a hash of the signed data snapshot. Editing signed data removes the signature automatically — this cannot be switched off. Designed for the requirements of 21 CFR Part 11; under Russian law (63-FZ) it is a simple electronic signature.
In which formats can we take our data?
CDISC ODM 1.3.2, Dataset-JSON 1.1 with Define-XML 2.1, SAS XPT, CSV and XLSX; casebooks as PDF/A. The closeout package carries data, metadata, audit and design and is verified by the recipient offline — without us.
How do updates affect a running study?
A release is published only after automated checks and a signed test run. The data schema only expands, a published design version never changes, and design changes go through an amendment — with subject migration and audit.
Can we move studies from OpenClinica?
CRF design moves over from OpenClinica 3.x templates and becomes a regular design version. The move is part of onboarding: we show it on your export and check the result together.
Do sites need to install anything?
No. The system runs in the browser; sign-in is by email and password, a second factor by organisation policy.
What does it cost?
It depends on the delivery model and the scale of work. We prepare an offer after the demo — for your scenario, with no obligation.
See it on your own scenario
We walk through the full cycle on a demo study — from eCRF design to a cut-off export.
- The full cycle: design, entry, cleaning, signature, export
- Validation and hosting questions answered from documents
- A sample vendor package — on request
We reply within three business days. Not a fan of forms? Write to us: info@x7insight.ru