Reading the regulation tells you what is required. It does not tell you what it costs, how it performs, or whether your existing estate can carry it. The sandbox exists so those questions can be answered against something running.
National and hospital-level EHDS decisions are being taken now, often on the basis of slideware. A working reference implementation lets a decision-maker prototype a feature, measure it, and decide with evidence instead of vendor assurance.
Stand up the stack, load templates and data, and exercise a real end-to-end flow rather than reasoning about one.
Two independent openEHR clinical data repositories run side by side, so conformance and performance can be compared rather than assumed.
Infrastructure as code, one command to provision, one to tear down. EU region by default — EHDS material stays in the EU.
Thirteen services in one deployable stack, behind TLS, with identity in front and two clinical data repositories behind.
| Layer | Component | Role |
|---|---|---|
| Capture | Form Builder | Authoring FHIR Questionnaires using Structured Data Capture |
| Capture | Form renderer | Filling questionnaires, producing QuestionnaireResponse |
| Exchange | FHIR server | EEHRxF-shaped exchange layer, FHIR R4 or R5 |
| Bridge | Mapping engine | Bidirectional FHIR ↔ openEHR, implementing the FHIR Connect mapping specification |
| Persistence | openEHR CDR (JVM) | Archetyped clinical persistence, templates, AQL |
| Persistence | openEHR CDR (Python) | Second independent implementation of the openEHR REST API |
| Identity | Identity provider | Authentication and access management, OIDC |
| Edge | Reverse proxy | TLS termination and certificate management |
Plus the databases each repository requires, and a portal that links the running services together for demonstration.
The sandbox is public. Every service is reachable directly, so you can inspect the APIs rather than take our word for what they do.
| Service | Entry point |
|---|---|
| Form Builder — author FHIR Questionnaires | forms.sandbox.ehds.technicise.eu |
| LForms — render and complete them | render.sandbox.ehds.technicise.eu |
| HAPI FHIR — exchange layer | fhir.sandbox.ehds.technicise.eu |
| openFHIR — FHIR ↔ openEHR mapping | map.sandbox.ehds.technicise.eu |
| EHRBase — openEHR CDR | cdr.sandbox.ehds.technicise.eu |
| Rogmukti — second openEHR CDR | rogmukti.sandbox.ehds.technicise.eu |
| Keycloak — identity and access | auth.sandbox.ehds.technicise.eu |
The sandbox is only interesting if data travels the whole way. It does.
We hold a generated openEHR benchmark corpus of roughly 205,000 synthetic electronic health records, together with the generator that produces it at any scale.
Ingest throughput, query latency and storage footprint at 10k, 100k and 1M records — the numbers a business case actually needs.
Independent comparison across CDR implementations and runtimes, using published methodology rather than vendor benchmarks.
A report a procurement team can hand to its board, produced before the platform decision is locked in.
We can stand one up for your organisation, extend it with the building blocks you care about, or run a benchmark against the CDR you are considering.