Skip to content
Field Report · Forge Tier · Healthcare Operations

Cross-Border Dental Network

Budapest, HungaryActive since October 2024

Fourteen chairs. Nineteen countries. Four hundred patients per month. One definitional layer. No system replaced.

Executive Summary

A Budapest-based dental clinic group generating over €8 million in annual revenue operates a cross-border patient acquisition network spanning 19 countries. The clinic runs 14 treatment units, an in-house dental laboratory, and processes 400–600 international patients per month — each requiring multi-visit treatment planning, travel coordination, and cross-jurisdictional data handling.

A unified event model connected the clinic's existing systems into a single operational layer. Estimated combined annual impact of ~€890K in Year 1 (~11% of annual revenue), with Year 2 projected at ~17%. Decision cycle compressed from 7-day manual planning to sub-minute event-driven visibility. No existing systems were replaced.

Decision cycleSub-minuteFrom 7-day manual
Year 1 impact~€890K~11% of revenue
Conversion visibility+30–35%Booking-to-arrival
Admin hours freed~1,200/moRedirected capacity
01 · The Environment

The clinic.

The clinic occupies a purpose-built four-story facility in Budapest's XIV district, operating 14 dental surgeries, two private consultation suites, and one of Central Europe's largest in-house dental laboratories. The laboratory operates as a separate production unit — manufacturing crowns, bridges, and prosthetic components on-site using VITA, Noritake, and Ivoclar materials.

The clinical team comprises 12–14 dentists, including three oral surgeons/implantologists, a specialist periodontist, and a specialist endodontist. Equipment includes a CBCT cone-beam scanner, KaVo Arcus Digma II jaw motion analyzer, and Zeiss OPMI Pico surgical microscopes. The implant portfolio covers Nobel Biocare, Straumann, Alpha-Bio, and DIO systems.

Dedicated local-number phone lines operate across 19 countries — including the UK, Ireland, Germany, France, the Nordics, the US, Canada, and Israel — each staffed by a named country representative. Patients travel for high-value procedures: full-arch All-on-4 rehabilitations, complex implant cases, and multi-unit bridgework. This is not a small dental practice — it is a vertically integrated manufacturing and clinical operation.

Operational parameters
Annual revenue€8M+
Employees84
Treatment units14
Dentists12–14 (incl. 3 oral surgeons)
Source markets19 countries
Monthly patients400–600 international
Avg case value€3,000–€15,000
In-house labSeparate production unit
02 · The Challenge

Definitional absence.

The visible problem was fragmentation. The structural problem was definitional absence. The clinic's systems did not disagree about data. They disagreed about meaning. The technology environment did not reflect the operational scale: WordPress with Elementor, two separate Facebook Pixel tracking IDs, no unified analytics model, no patient portal, no online booking.

The internal clinical environment had no API surface. The clinic was connected to EESZT — Hungary's national electronic health platform — but this operated as a regulatory compliance endpoint, not an operational data source. The result: an organization generating over €8 million annually, treating patients from 19 countries, managing the entire demand side through phone calls, email threads, and disconnected spreadsheets.

Previous technology vendors had addressed individual symptoms: a better website, improved SEO, call tracking. None had engaged with the structural question. At least two vendors declared unifying patient identity across a 19-country inbound funnel “not feasible” — citing the absence of API surfaces, no shared keys across country channels, and cross-border compliance complexity. The conclusion: replace the core systems first. The systems stayed. The problem stayed with them.

Definitional gaps identified
GAP-01“Patient”

A “patient” in the UK phone line was a person who had called. In the clinical system, a person who had been examined. In EESZT, a person for whom a clinical event was registered. Three definitions coexisted without reconciliation. Every downstream process inherited the incoherence.

GAP-02“Conversion”

In the website layer, conversion meant a form submission. For the country representative, a confirmed travel booking. In the clinical system, treatment commencement. The clinic could not answer what percentage of interest converts to delivered treatment — the question itself was undefined.

GAP-03“Revenue event”

A full-arch case might span two or three visits over months, with surgical phases and restorations billed at different points. Whether this was one revenue event or three was not standardized. Financial reporting functioned, but the relationship between what was reported and what occurred was mediated by manual interpretation.

GAP-04Capacity planning

Fourteen chairs and a finite dental laboratory represent hard constraints. Without a unified model of incoming demand by treatment type, complexity, and source market, the clinic allocated capacity reactively — by experience and informal coordination, not by a forward-looking model.

“The constraint was not data. It was the absence of a system that defines what data is allowed to mean.”

Stathon field observation
03 · The Engagement

Four modules. Three phases.

Phase 1 · Weeks 1–6

Arch\u00E9 · Definitional Authority

Established the domain ontology for cross-border dental operations. The entity graph declared four primary entities: Patient (deduplicated across all systems and country channels), Case (bounded treatment engagement), Visit (physical attendance event), and Revenue Event (billable milestone with defined recognition rules).

The event schema codified lifecycle transitions from initial inquiry through treatment completion and guarantee-period monitoring. The compliance model declared data governance boundaries for cross-border patient records — including the tension between GDPR's right-to-erasure and the Hungarian Health Data Processing Act's 30-year retention requirement.

Core · Operational Continuity

Established the event-driven data movement architecture across five source systems. The normalization layer performed source system fingerprinting — tagging every event with its origin, extraction method, and temporal reliability grade.

Idempotent state transitions ensured that duplicate patient records arriving from multiple country channels were reconciled into a single entity without data loss. The initial deduplication pass identified approximately 8–12% overlap in the active patient pipeline across country channels.

Systems integrated
Internal clinical environmentStructured batch extract6–8 hours
EESZT (national eHealth)Structured interfaceNear-real-time
WordPress / Elementor web layerReal-time event capture<1 second
Country channels (×19)Daily structured import24 hours
Laboratory production workflowSemi-automated input2–4 hours
Phase 2 · Months 2–4

Athena · Intelligence & Foresight

Patient flow scoring. A probabilistic engine assigns conversion-likelihood scores to every active entity, updated on each new event. In production, it surfaces the 15–20% of the pipeline most likely to convert within 30 days.

Booking yield optimization. Combines patient flow scores with treatment-type classification and dental laboratory load profiles to generate a forward-looking demand composition model for a rolling 6–8 week window.

In March 2025, the scoring engine flagged five concurrent full-arch rehabilitation cases from the Irish channel targeting the same two-week window — exceeding the laboratory's zirconia production capacity by approximately 30%. Two cases were redistributed before patients booked flights, avoiding an estimated €12K–€30K in potential revenue disruption.

Aegis · Sovereignty & Protection

The RBAC policy schema governs data access across four authorization tiers: clinical staff, coordination staff, country representatives (market-restricted), and management. Every data access event — human or algorithmic — is logged with full retrieval guarantees.

The data subject lifecycle model manages the interaction between GDPR erasure rights and Hungarian law's mandatory 30-year medical record retention. The UK data transfer framework was designed with Standard Contractual Clauses as a structural fallback alongside the EU adequacy decision.

Phase 3 · Current

Refinement of the predictive scoring model based on twelve months of production data. Extension of the dental laboratory load forecasting model to material-specific constraints. Development of a treatment-complexity prediction layer using pre-arrival diagnostic imaging — technically validated, operating under human-in-the-loop protocol pending clinical team sign-off.

04 · Outcomes

Measured results.

Decision cycle
7-day manualSub-minute
6–8 week forward window
Year 1 impact
Baseline~€890K
~11% of annual revenue
Conversion visibility
Fragmented+30–35%
Booking-to-arrival, 19 markets
Admin hours freed
~1,080–1,300/moRedirected
To patient-facing work
Entity deduplication
Unknown overlap8–12% identified
Cross-channel duplicate patients
Compliance framework
FragmentedUnified
GDPR + Hungarian + UK post-Brexit
Six-layer financial impact model
Liberated labor capacity€230K–€390K/yr1,080–1,300 admin hours/month redirected from manual reconciliation
Avoided capacity loss€27K–€37.5K/yrThree dental laboratory collision events identified and avoided
Case-mix optimization€90K–€200K/yrChannel-level visibility enabling high-value case recovery
Capacity utilization uplift€250K–€400K/yr3–5% effective utilization improvement across 14 chairs
Acquisition cost efficiency€100K–€160K/yrROI-driven budget reallocation across 19 channels
Patient lifecycle extension€80K–€130K/yrReturn-visit capture and referral attribution
05 · Observations

What the surface does not show.

The Stathon infrastructure deployed within this clinic group is not a tool and not a platform. It is the operational logic layer that governs how the organization understands its own activity. Before the engagement, the clinic operated fourteen treatment chairs, an in-house dental laboratory, and a 19-country patient acquisition network — and could not consistently answer whether a given individual was a prospect, a patient, or a completed case.

The clinic's existing systems remained in place. WordPress still serves the website. The internal clinical environment still records treatment data. EESZT still receives regulatory submissions. Country representatives still manage their phone lines. None of these systems were replaced, modified, or re-architected. What changed is that they now operate beneath a coherent operational intelligence layer.

The organization did not hit a market ceiling. It hit the limit of what it could define, measure, and allocate coherently — and that limit was resolved not by adding capability, but by establishing the definitional authority that makes capability meaningful.

“What previous vendors declared impossible was not a technical limitation. It was a question of whether anyone was willing to do the definitional work first.”

Stathon field observation
06 · What Is Live, What Is Next

Forward.

Current

Treatment complexity prediction

Pre-arrival diagnostic imaging analysis to estimate chair-time and visit-sequence requirements. Technically validated, operating under human-in-the-loop protocol pending clinical team sign-off on confidence thresholds.

In development

Laboratory material load forecasting

Extending the capacity model to material-specific constraints — zirconia, PMMA, ceramic throughput — for production scheduling.

Roadmap

Source market demand elasticity

Predictive layer addressing how pricing changes in specific markets affect demand composition, case mix, and capacity utilization.

Roadmap

Referral attribution and network effects

Quantifying the relationship between patient satisfaction, review volume, and organic acquisition across source markets.

07 · Engagement Parameters
Engagement typeForge Tier · Healthcare Operations
Engagement startOctober 2024
Phase 1 completeDecember 2024
Full productionJanuary 2025
Current phasePhase 3 — expansion and refinement
Clinical environmentLegacy PMS (no API) · EESZT · WordPress
Regulatory frameworkGDPR · Hungarian Act XLVII · UK post-Brexit transfers
Systems modifiedNone — batch extract + event capture integration

Client identity withheld by agreement. Deployment metrics reflect production conditions as of March 2026.