Technical details · Tidegate
The Tidegate engine

Technical details

For engineers, architects and security reviewers: formats, linkage controls, tokens, deployment, and how the engine is tested and updated.

Where it sits

One foundation, four layers.

Pick your market to see the uses, deliverables, layers and data that matter to you.

{{ segCap }}

USES
{{ x.k }}{{ x.v }}
DELIVERED AS
{{ x.k }}{{ x.v }}
THE ENGINE
{{ x.n }}{{ x.k }}{{ x.v }}
Foundation · ontologyWhat every field is, which rules govern it and what it may be used for.
YOUR DATA
{{ x.k }}
Layer 1 · Discovery

Reads what you exchange, including what nobody structured.

Zero-shot discovery finds identifiers and clinical entities across structured tables, free-text notes and the documents embedded inside HL7, FHIR and C-CDA messages, including documents with a text layer. From v1.1: scanned documents. You see what a dataset holds before anything is linked, shared or licensed.

In · structured
{{ x }}
In · unstructured Documents are read from their text layer, or from text your systems already produce. From v1.1: redaction of scanned documents. The engine does not call text services outside your environment.
{{ x }}
Diagram of the Tidegate engine: your data flows through discovery, protection, linking and labeling, inside your environment, and out as protected datasets, link tables and reports. The Tidegate engine DISCOVER · PROTECT
LINK · LABEL
Out
{{ o.k }}{{ o.v }}
Standards and file types in detail
{{ d.k }}{{ d.v }}
Layer 2 · Protection

Protect it in your environment, and build before it is cleared.

De-identification covers structured data and free-text notes, with one keyed replacement per person in Expert Determination mode, so histories hold. Text and documents with a text layer can also be returned as redacted copies, with every redaction logged. From v1.1: scanned documents. On the roadmap: images. Synthetic data for development and testing is released only after memorization tests, with a synthetic data report. Feasibility comes from real counts measured in your environment.

DE-IDENTIFICATIONStructured data and notes
  • The same replacement in every table and note
  • Per-person date shifts keep intervals, in Expert Determination mode. Safe Harbor mode keeps the year only.
  • A re-identification risk summary with every release
SYNTHETIC DATABuild and test, before clearance
  • Mirrors the structure of the source
  • Structure to build against, not patient counts
  • Build and test before real data is cleared
  • Released only after memorization tests, with a synthetic data report
Layer 3 · Entity linking

You decide how sure is sure enough.

Each candidate pair gets a match score. Above your threshold, records are linked and the evidence is logged. Below it, the pair goes to your review queue.

A wrong merge puts one history in someone else’s record. A missed link splits one history in two. Move the slider to see the balance.

More to reviewMore linked

Illustrative pairs and MATCH scores. Illustrative threshold: 0.80, set by your team.

Linked, with evidence{{ appliedCount }}
{{ d.t }}{{ d.e }}{{ d.cs }}
To your review queue{{ reviewCount }}
{{ d.t }}{{ d.e }}{{ d.cs }}
Existing tokens

Works with the tokens already in your data.

Most real-world data already carries tokens. The engine reads them, weighs them as evidence and passes them through, and it issues holder-issued, purpose-scoped pseudonyms, so you are not tied to one vendor’s identity.

Token types read as identifiers
Commercial tokenization services Real-world data network IDs Your own hashed IDs Bloom-filter encodings

We confirm the token types in your data during scoping.

  1. 01ReadToken columns are recognized as identifiers, alongside names, birth dates, addresses and source IDs.
  2. 02WeighA shared token from the same vendor and key counts as strong evidence for a link. It is weighed with everything else, including identifiers found in notes, so one bad token does not merge two people.
  3. 03Carry throughToken columns pass through unchanged and appear in the link table next to the Tidegate ID, so partners can still join on them.
  4. 04Link across partiesROADMAPWhere two parties share a token vendor, they join on those tokens as they do today. Where they do not, holder-issued pseudonyms shared across parties will let the same person match in both datasets.
Layer 4 · Interoperability

Governed movement, once the data is ready.

After discovery, protection and linking, data moves into the formats your teams and partners use. Labels travel with it, so each destination enforces the same rules.

OUTPUT FORMATSLABELS ATTACHED
OMOP CDMIncluding NOTE_NLP, with citations to the note
CSV and ParquetThe same schema as the input
Link table and crosswalkSource ID to one person, merges and splits logged
Labels and reportsJSON: field labels, permitted uses and risk summary
FHIR R4FROM V1.1With Provenance, so each value keeps its source
Release continuity

One person, one identity, every release.

A one-time privacy review goes stale when the next dataset arrives. Tidegate keeps released values stable and ships a re-identification risk summary with every release.

RULESON EVERY RELEASE
{{ c.k }}ROADMAP{{ c.v }}
RELEASE LOG · TDG-4Q7XILLUSTRATIVE
{{ l.r }} {{ l.k }}{{ l.v }}
Deployment

In a cloud account you control.

Models run locally, with no calls to outside AI services and nothing phoning home. Deployed and operated with Tidegate Forward Deployed Engineers, under a BAA whenever they access PHI. From v1.1: on premises and air-gapped installs with signed offline updates.

{{ way.tag }} {{ way.title }}

{{ way.body }}

Best for{{ way.best }}
{{ sg.t }}

Illustrative examples. Package and field names may differ in your installation.

Where it runs

Deployment
Private cloudManaged Kubernetes · your account or subscription
Your Kubernetes clusterIn your cloud account · signed images · installed with Helm
On premisesFROM V1.1Your data center · your hardware
Air-gappedFROM V1.1No outside connection · signed offline updates

Models run locally in every option. Delivered with Tidegate Forward Deployed Engineers today; packaged installs from v1.1. Supported providers and regions are covered in a briefing.

Updates

How it gets better without pooling your data

Your records are never pooled or sold. The engine improves through four channels you control, and you decide when each new version goes live.

01 · OPT-INCorrections, not recordsWhen reviewers confirm or reject a link, you can choose to share the decision as a structured signal, without the records behind it.
02 · UNDER AGREEMENTEvaluation in your environmentLabeled pairs for evaluation are built with you, under written agreement, and stay where your records are.
03 · SYNTHETICHard cases, generatedFictional examples of the rare errors: twins, name changes, shared addresses, transposed dates and partial identifiers.
04 · RELEASESSigned, approved, reversibleEach engine release is signed and ships with its evaluation results. You approve rollout and can roll back. From v1.1: signed offline bundles.
Comparison

What you have today, and what it adds.

Tidegate does not replace these tools. It adds the meaning, permission and proof they leave out.

ApproachGood atWhere it stopsWhat Tidegate adds
{{ c.a }}{{ c.g }}{{ c.s }}{{ c.x }}

Request a technical briefing

Walk through the API, deployment and testing method with our engineers.