Documentation
Documentation
TIGER platform documentation
How data gets into the TIGER registry, how it comes back out, and how the numbers on your dashboard are calculated. Written from the behaviour of the running system, not from a plan.
What this platform is
The TIGER Study is a multinational registry of oesophageal and gastro-oesophageal junction cancer surgery. This platform is its electronic case report form (eCRF) and the analytics and data-exchange tooling built around it. It replaces the study's original Drupal webform: the field inventory documented here was exported from that form, and the record structure, controlled vocabularies and field keys were carried across unchanged so that historical records and new entries share one schema.
The migration is deliberately staged per institution. While a site is in its parallel run, the legacy system remains the source of truth and reconciliation runs compare the two datasets; writes that would create divergence are refused with an HTTP 412 and a plain-language explanation in the interface. Once an institution clears its cutover gate, writes land directly in this platform. If you see “import paused — institution is in the parallel run”, nothing you did was lost: the staged, reviewed and signed batch is kept in full and can be promoted once your institution is cut over.
Patient data is held per institution. Identifying sections of each record are stored encrypted; the plaintext columns are the clinical aggregates that analytics reads (lymph-node counts, complication grade, mortality flags, stage groups, resection margin and so on). Every export and every import is written to an audit log with the acting user, their role, their IP address and the study.
Who these guides are for
Three audiences, with different amounts of the platform visible to them:
- Site investigators and research nurses — entering and checking records for one institution. You see your own institution's patients, your own institution's analytics (against a global benchmark) and your own institution's import/export history.
- Data managers and institution administrators — the same institution scope, plus the ability to start an import, correct staged rows, sign the submitter agreement and promote a batch into the live dataset.
- Study administrators — cross-institution scope: the institution leaderboard, cross-institution comparisons, and the tier that can run an unscoped global export or an export that includes protected health information.
Where a capability is restricted, the guide says which role tier is required. The tiers are mostly nested — a project administrator can do what an institution administrator can — with one deliberate exception worth knowing before you read the rest.
“Or higher” does not include the study administrator
The study administrator role sits above institution administrator and sees everything, but it is read-only across the whole platform: it observes the study without changing it. It cannot start an import, correct a staged row, sign a submitter agreement or promote a batch, even though a role beneath it can. Where a guide says “institution administrator or higher”, read it as the write-capable tiers.
The six guides
Quick answers
How do I add a patient?
Sign in, open Patients in the dashboard sidebar and use New Patient to start a record. The eCRF is organised into the nine sections listed in the data dictionary, and each section is saved independently — a record can sit part-complete while you wait for pathology or follow-up. The completion percentage shown against a record is the number of completed sections out of a fixed denominator of eight. If you have a spreadsheet of existing patients rather than one new case, use the import wizard instead of typing them in.
How do I export my institution's data?
Open the Data Exchange page, pick a format (CSV, Excel, CDISC ODM XML or FHIR Bundle), optionally add filters, and create the export. The scope is decided by the server, not by you: unless you hold a study-admin role, the export is pinned to your own institution and naming a different institution in the filters is rejected. See Data export for what each format contains and how downloads are watermarked.
How do I read my analytics?
The analytics dashboard shows your institution against the global benchmark for the same period. Two things to know before you draw a conclusion: any count below five is suppressed and returned as “no value” rather than a number, and several familiar metrics (length of stay, ICU days, readmission) have no plaintext source in this registry and are therefore not reported at all rather than reported as zero. The analytics guide defines every metric and its denominator.
How do I get access?
If your institution already participates, ask your institution's administrator for a registration code and complete the form at /register. You will be asked to set up a second authentication factor before you can reach patient data. If your institution does not yet participate, start at /apply — applications are reviewed by the study committee.
Getting help
These guides describe what the software does. For questions about the study protocol, eligibility, a specific record, or an access problem your institution administrator cannot resolve, use the study contact page.
Contact the study
Coordination, regional and technical contacts are listed on the contact page. Please do not include patient identifiers in any message — quote the study number of the record instead.
Where these pages come from
Every statement in this documentation is derived from the platform source: the API endpoint definitions, the import and export services, the analytics queries and the eCRF element export. Where behaviour is undefined in the code — for example a retention period that is not implemented — the guides say so rather than inventing a number.