Access
Three ways to query, one boundary
We call the access environment Theatrum. Whichever mode you use, the identified data stay in their country of origin, today Argentina, and what leaves is an aggregate you can defend in a submission.
Modes
The three access modes
- 01 SQL over aggregates
Clean Room
Your analysts work inside our environment on de-identified OMOP tables. Queries run against the data; only aggregated results leave, after an automated small-cell check and a human output review.
- Who it is for
- Pharma and CRO analytics teams who want to write their own cohort logic and iterate quickly.
- What comes back
- Aggregate tables, descriptive statistics, model outputs. No row-level export.
- 02 The protocol travels, not the data
Federated node
You send an analysis package. We run it against the OMOP instance and return summary tables. The node is designed for compatibility with OHDSI network studies, so a protocol written for other OMOP sites can run here without rewriting.
- Who it is for
- Multi-country studies, academic networks and sponsors who already work in OHDSI tooling.
- What comes back
- Study result sets as defined by the package, reviewed before release.
- 03 Counts before commitment
Feasibility API
Submit inclusion and exclusion criteria and receive rounded patient counts and basic distributions. Useful for protocol design, site selection and recruitment estimates before any agreement is signed.
- Who it is for
- CROs planning trials, pharma teams scoping a study, partners testing a hypothesis.
- What comes back
- Rounded counts, age and sex distributions, time windows. Nothing below the minimum cell size.
Flow
From source to delivery
Identified records are pseudonymised inside the country of origin, today Argentina, before they reach the data platform. Everything a client touches sits downstream of that step.
- 01
Sources
Payer claims and hospital clinical systems, exported via FHIR R4.
- 02
Pseudonymisation
Hashed and salted tokens, date shifting, age banding and geography reduction. Performed in Argentina.
- 03
Fabrica · OMOP CDM
Standardisation to OMOP with OHDSI vocabularies, quality checks and the data dictionary.
- 04
Theatrum · Delivery
Clean Room, federated node and Feasibility API. Output review before anything leaves.
Comparison
Choosing a mode
| Attribute | Clean Room | Federated node | Feasibility API |
|---|---|---|---|
| You send | Analysts and SQL | An analysis package | Criteria |
| You receive | Aggregates and model outputs | Summary tables | Rounded counts |
| Row-level access | Inside the environment only | None | None |
| Typical use | Custom RWE study | Multi-site OHDSI study | Protocol feasibility |
| Agreement required | Yes | Yes | Light-touch |
Process
How an engagement runs
- 01
Question
You describe the clinical or commercial question and the population of interest.
- 02
Feasibility
We return counts and coverage against the data dictionary, usually via the Feasibility API.
- 03
Protocol and review
A protocol is agreed and reviewed by the scientific and ethics committee.
- 04
Access
Work proceeds in the Clean Room or through the federated node under a data access agreement.
- 05
Output review
Results are checked for disclosure risk and released with documentation of the pipeline.