Building Health-Tech in Croatia for a UK Diagnostics Company: Data Residency, Contracts, Time Zones, and Four Things We Got Wrong

Where the data physically lives, and who decided that

Personal data and sample-linked records sit in EU-region managed databases and EU-region storage buckets, with the UK entity acting as data controller and the Croatian engineering team operating strictly as processor. Region selection was a contractual decision made with the client's data protection officer, not an engineering default, and it is written into the DPA.

The practical mechanics matter more than the label. Some managed databases, Firestore among them, fix their location at creation time, so the region choice is effectively permanent for that project. That single constraint forces the residency conversation to happen before the first line of production code, alongside questions most teams defer: does the laboratory information system export leave the EU, does the transactional email provider store message bodies, does the error tracker capture request payloads containing an email address or a sample barcode.

We split storage by sensitivity rather than by system. Identifiable customer records, consent artefacts, and anything joinable to a sample barcode live in EU regions with restricted service accounts. Aggregate, de-identified analytics can move into a warehouse with looser access, because the join key never travels with it. That separation is what makes an access review tractable: you can answer 'who can read identifiable health data' with a list of four service accounts rather than an architecture diagram.

The DPA clauses that actually changed the architecture

Four clauses in the data processing agreement had direct engineering consequences: sub-processor notification, deletion and return of data on termination, breach notification windows, and audit rights. Each one turned into a build item, not a policy document, because none can be satisfied retroactively by a team that already shipped.

Sub-processor notification is the one that bites hardest in practice. Adding an email provider, a PDF renderer, a queue service, or an error tracker is a two-minute decision for an engineer and a contractual event for the controller. We now keep a sub-processor register in the repository, reviewed at the same cadence as dependency updates, and any new third party that touches personal data goes through the client before it goes into a package.json.

Deletion rights shaped the data model. Because the UK entity is the controller and fields deletion requests from customers, the engineering side has to make deletion an executable operation rather than a manual database session. That means every identifiable record carries a subject reference, results are separable from identity, and the parts that must be retained for laboratory or accounting reasons are stored in a form that survives the deletion of the person. Audit rights meant logging who read what, which is cheap to build on day one and expensive to reconstruct in year three.

• • Sub-processor notification: a versioned register in the repo, client approval before any new dependency that processes personal data
• • Deletion on request and on termination: subject-keyed records, identity separable from results, retained records de-identified rather than kept whole
• • Breach notification: alerting and access logs designed so the controller can be told what was exposed inside the contractual window
• • Audit rights: read-access logging on identifiable collections from the first release, not bolted on later

Controller versus processor: what it changes day to day

The UK diagnostics entity is the controller and decides why and how personal data is processed. The Croatian engineering team is a processor acting on documented instruction. In practice this means engineers do not decide retention periods, do not approve new data uses, and do not action a deletion request that arrives directly in their inbox.

The distinction sounds bureaucratic until a customer emails an engineer asking for their data to be erased. The correct answer is not to run the deletion. It is to route the request to the controller, who verifies identity, checks whether legal or clinical retention obligations apply, and then instructs the processor. We built the deletion tooling so that it is triggered from an admin action taken by the client's staff, with the engineering team owning the mechanism and the client owning the decision.

The same split governs analytics and AI. Any proposal to feed customer records into a new tool, a new dashboard, or a model prompt is a controller decision about purpose. Engineering can say what is technically possible and what the privacy cost is. It cannot unilaterally decide that a legitimate interest exists.

Time zones: a Croatian team, UK clinician sign-off, and US customers

Croatia sits one hour ahead of the UK and six to nine hours ahead of the US. That gives roughly seven overlapping working hours with London and two to three with the US East Coast. The engineering rhythm is built around that: clinician-facing changes land in the morning Central European Time so the UK side has a full day to review.

Clinician sign-off is the constraint that shapes release timing more than anything else. Result release in a diagnostics product is gated on a human review step, and that human works UK hours. A change to how results are rendered, ordered, or flagged is not shippable until a clinician has looked at real output. We schedule those reviews as calendar events with a named reviewer rather than as a Slack request, because a Slack request sent at 17:30 CET is a next-day request in practice.

Support was the harder problem. Customer-facing support hours have to cover US customers, which extends well past the Croatian working day. The workable arrangement was to keep first-line support with the client's own team, aligned to customer geography, and to define a narrow escalation path into engineering with a written definition of what counts as urgent. Engineering does not staff a 24-hour rota. It staffs a defined on-call window plus a documented severity ladder, and everything below that severity waits for the morning.

Contracting and invoicing across three jurisdictions

The structure is straightforward once written down: a Croatian company contracts with a UK-registered company, invoices in a single agreed currency under a master services agreement with a schedule per workstream, with the DPA attached as a separate annex. Intellectual property assigns to the client on payment, and repositories live in the client's organisation from day one.

The details that cause friction are mundane and worth settling early. Which VAT treatment applies to B2B services between a Croatian supplier and a UK customer post-Brexit, and who is responsible for the reverse charge. Which currency the invoice is denominated in and who absorbs the FX movement. Payment terms measured in days from invoice date rather than 'end of month', because two different fiscal calendars produce two different answers. Whether the client's procurement process requires purchase orders, which changes when work can legitimately start.

We keep the commercial agreement and the data agreement as separate documents on purpose. Commercial terms get renegotiated as scope changes. Data terms should not have to be reopened every time the rate card or the team size changes, and separating them means a scope amendment does not accidentally reset the sub-processor list or the retention schedule.

The four things we got wrong

Four mistakes stand out from years of cross-border delivery: we picked a database region before the residency conversation was finished, we added a sub-processor without notifying the controller, we designed a support rota with a five-hour gap, and we built a lab integration on the assumption that the lab would always be in the UK. Each was recoverable, and each cost more than the conversation that would have prevented it.

The region mistake was the most structural. Firestore location is immutable per database, so a project spun up quickly during early development inherits a region decision made before anyone asked where the customers or the lab would be. Correcting it means a migration, not a config change. The rule we now follow is that no production project gets created before the residency question has a written answer from the client.

The sub-processor mistake was a transactional email provider added during a sprint because it solved a deliverability problem. It was a good technical choice and a contractual miss, because message bodies contained personal data and the controller had not been notified. The support gap was arithmetic: European on-call ended and US-facing coverage had not begun, leaving several hours where an urgent issue had no named owner. The lab integration assumption was the subtlest. We modelled a single laboratory with UK-specific identifiers, units, and turnaround expectations baked into the schema. The moment a second processing site entered the picture, every one of those assumptions needed a column and a migration. Regulated products expand geographically, and the schema should assume more than one of everything: one lab, one jurisdiction, one clinician pool, one shipping regime.

• • Region chosen before residency was agreed: Firestore location is immutable, so this becomes a migration rather than a setting change
• • Sub-processor added without notice: a good engineering decision that skipped a contractual step
• • Support rota with a five-hour gap: on-call windows must be checked as arithmetic across all customer time zones, not assumed
• • Lab integration built UK-only: identifiers, units, and turnaround rules hard-coded to one site and one jurisdiction

The data-model side of this, pseudonymization pipelines, retention enforcement, and audit logging, is covered in more depth in our write-up on privacy-preserving architecture patterns.