Solutions Nubiss StudyCore
Nubiss StudyCore — eCRF
Define electronic case report forms, catch problems at the point of entry, resolve them through queries, and sign records under a change history where tampering shows.
An out-of-range value raises a query automatically, with the rule that raised it recorded against it.
The problem
The cost of a data problem grows with how long it goes unnoticed — and on paper, it goes unnoticed until the monitor visits.
Filled in at the bedside, transcribed later, and corrected in a margin nobody else will read.
Three sites working from three revisions of the same form, discovered at the first monitoring visit.
A data problem costs more the longer it goes unnoticed, and on paper it goes unnoticed for months.
With Nubiss
The same study, with the structure decided before the first subject rather than after the last.
The form is rendered from the study's own definition, so every site enters the same fields the same way.
Rules run on submission: hard violations block, soft ones open a query against the value that raised it.
Source data verified field by field and locked, then signed with password re-authentication.
Who it is for
Interventional and observational, phase I to IV or no assigned phase, across one site or many.
Study setup
The work is front-loaded on purpose: every decision made here is one the site team cannot get wrong later.
Protocol identifier, phase, sponsor; then the sites with centre identifiers and countries.
Sponsor, CRO, monitor, investigator, data manager or administrator — scoped to one site or the whole study.
Numbered versions holding fields with a code, a type, required status and permitted values.
Day offsets with windows, so an out-of-window visit is flagged rather than silently accepted.
Hard checks block completion; soft checks open a query automatically.
A study can also be cloned from a template — visits, forms, fields and randomisation configuration copied in one step.
Capture and cleaning
Refuse the obvious errors immediately; give the arguable ones a documented conversation.
At the site
A date field is a date picker, a choice field is a fixed list — no separate form to maintain.
Required fields, ranges, patterns, permitted choices and unknown codes checked before a form completes.
Visit windows, form states, open queries, verification coverage and samples — one screen per subject.
Data management
Open → answered → closed with a comment thread; a rule-raised query records which rule raised it.
Field-by-field verification with a lock; a locked form cannot be edited at the site.
Subjects, visits, forms, samples and open queries, broken down by site.
Record integrity
Signatures bound to the data as signed, and an audit trail designed so tampering is detectable rather than merely prohibited.
Username and password again at the moment of signing, with the signer, time, printed name, meaning and reason recorded.
A SHA-256 hash over the record as signed, re-verified on view. If the data changed, the signature no longer matches.
A signed form cannot revert to incomplete; a verification lock independently blocks site editing. Un-signing needs re-auth and a reason.
Actor, time, action, before and after values — with a field-by-field difference view.
Each event carries the hash of the one before it. Altering a past event breaks the chain from that point on.
Audit records live in their own database and reject updates and deletions at the application layer.
Randomisation and blinding
Lists are generated from a recorded seed — the same seed reproduces the same list, years later.
Stated limits
Subject privacy
A subject record holds a study identifier, sex and year of birth — no name, no medical record number. Identifying details live separately, encrypted, with access restricted by role and logged.
Worth knowing: date of birth is currently stored unencrypted alongside the encrypted fields.
Biospecimens
Auto-generated laboratory identifiers, aliquots linked to their parent, storage from freezer to position — and every movement recorded as an event with who, when, from, to and at what temperature.
Compliance
Where StudyCore genuinely sits against regulatory expectations for computerised systems in clinical trials — stated without interpretation.
| Area | Position today | Status |
|---|---|---|
| Audit trail | Actor, timestamp, action, before and after values, address and session, on a separate append-only database with a hash chain. | Available |
| Electronic signature | Password re-authentication, meaning of signature, printed name, reason, and a SHA-256 hash binding the signature to the data as signed. | Available |
| User management | Role-based permissions scoped by company, study and site; failed-login lockout; time-boxed secondary roles. | Available |
| Data integrity at entry | Type, range, pattern and choice validation, plus configurable edit checks that block or raise a query. | Available |
| Reason for change | Captured when a record is signed or a signature is removed. Not prompted on an ordinary data edit. | Partial |
| Form version control | Versions are numbered with draft, active and retired states and effective dates. The software does not currently prevent an active version from being edited — control is procedural. | Partial |
| Study data export | No export of collected study data in any format. The audit log exports to CSV. | Planned |
| Backup, archiving, retention | Not implemented in the application. Any arrangement is at the hosting layer and is not documented here. | Planned |
| Validation documentation | No installation, operational or performance qualification package, no validation plan and no traceability matrix is available today. | Planned |
StudyCore is not presented as GCP compliant, 21 CFR Part 11 compliant, EU Annex 11 compliant, ISO certified or validated. Several of the technical controls those frameworks call for are implemented and described above, and they are described so that your quality function can assess them. Assessment against a framework requires documentation that does not yet exist, and computerised system validation for your study remains your responsibility.
If a formal validation package is a precondition for you, say so in your enquiry — it changes the conversation and we would rather have it early.
Questions
Every answer here is the honest one — including the things the product does not do yet.
Today, you cannot export collected study data from the application in any format — the most significant gap in the product, and we would rather you heard it here than in a demo. The audit log exports to CSV.
No. Forms are built through configuration screens, one field at a time. Cloning a study template is usually faster than building from scratch.
No. There is no ODM, no Define-XML, no SDTM mapping and no CDISC controlled terminology. Permitted values are defined per field as a fixed list.
Not in StudyCore. Programming interfaces exist in the codebase but are not exposed, so StudyCore has no integration surface today, and no FHIR or HL7 support. This is a StudyCore limit rather than a Nubiss-wide one — Nubiss TelMed does have a FHIR R4 interface, but it is a separate product and covers Telekonsil records, not study data.
Multiple instances of a form can exist for a subject and visit, but repeating item groups within a single form are not part of the schema.
An adverse event form template ships with the standard field set, so events can be recorded as data. There is no dedicated safety workflow — no seriousness and causality assessment, no expedited reporting, no MedDRA coding.
Not in practice. A rule can be marked as cross-form, but it is evaluated only against the form being submitted, so it cannot reference another form's values.
We will walk through how your visit schedule, forms and edit checks would be configured, and be straight about anything StudyCore cannot do for your study. Please do not include any participant information.
