How Zaynix Health handles your clinical data.

01

Terminology architecture.

The platform uses four international clinical terminology standards. Where a confident match exists, a record carries its code.

LOINC — laboratory observations

A blood marker that reaches the longitudinal chart is mapped to a Logical Observation Identifiers Names and Codes (LOINC) concept where one exists for it; a marker without a clean match is kept under the lab's own name and flagged for review. LOINC is the international standard for laboratory tests and clinical observations. The mapping is what makes an HbA1c on a Medichecks panel comparable to an HbA1c on an NHS pathology report two years later, even though the panels were ordered, drawn, and reported by different organisations.

The set of LOINC concepts the platform recognises at first pass includes the following common markers — codes shown verbatim:

Markers outside this set are still ingested and surfaced — but they go through the platform's flexible-extraction layer first, where they're either matched to an existing LOINC concept with a confidence score or routed to a patient-confirmation workflow before they enter the trusted record.

SNOMED CT UK — clinical concepts

Clinical concepts — diagnoses, allergens, procedures, findings — resolve against SNOMED CT, UK Edition. SNOMED CT is the terminology already used across NHS systems for clinical content; the UK Edition adds UK-specific extensions on top of the international release. The platform uses concept IDs (numeric) and preferred terms (human-readable) from the same hierarchy NHS systems use, so a recorded diagnosis carries the same concept ID NHS systems use.

SNOMED's hierarchy is what lets 'amoxicillin' (SCT 372687004) and 'penicillin' (SCT 764146007) be recognised as related concepts even though the words differ.

NHS DM+D — medicines and devices

Medications are resolved against the NHS dictionary of medicines and devices (DM+D) — the same dictionary NHS prescribing systems use. DM+D gives every drug a stable identifier, a preferred name, and a route through brand → generic → ingredient that lets the platform reconcile the same medication recorded under different names across different documents over time.

UCUM — units of measure

Units are handled explicitly via the Unified Code for Units of Measure (UCUM). An HbA1c reported as mmol/mol from one lab and % from another resolves to a comparable value on the same chart. Cholesterol in mmol/L from a UK lab and mg/dL from a US private panel are converted at read time, not at write time, so the original source value is always recoverable.

02

Terminology servers.

Terminology mapping isn't done from a hand-curated lookup table. It's done against the same FHIR terminology servers the NHS and the international LOINC community publish.

NHS Terminology Server — SNOMED CT UK

SNOMED CT UK lookups are served by the NHS Terminology Server via its FHIR endpoint, authenticated with OAuth2. When an allergen, condition or procedure is recorded, the platform calls the FHIR $expand or $lookup operation, retrieves the preferred term and semantic tag, and writes both onto the record alongside the concept ID.

Regenstrief LOINC FHIR — laboratory observations

LOINC concepts for blood markers are resolved against the Regenstrief LOINC FHIR server. Marker names are normalised first — including UK→US spelling normalisation (haemoglobin → hemoglobin) — before search, so a UK pathology PDF that uses British spelling still resolves to the same LOINC concept as a US lab.

Cache-per-concept strategy

Every terminology lookup is cached at the concept level. The first time the platform resolves "Penicillin" to SCT 764146007 via the NHS server, that mapping is written to the local terminology cache. Every subsequent allergen recorded as "Penicillin" — on any record — uses the cached entry. Terminology service availability isn't on the hot path of routine clinical use.

Disambiguation when the LLM can't pick one

When the terminology server returns multiple candidates that scoring can't narrow down with confidence, the platform doesn't guess. The record is flagged with an amber "possible matches" indicator and the patient is asked to pick the right concept from a short list. The decision is then written to the audit log and used to extend the cache, so the same ambiguity doesn't surface twice.

03

Provenance and audit.

Source-document linking

Every extracted value links back to the source document it came from. A clinician viewing a marker on a longitudinal chart can click through to the original PDF — the value, its reference range, and the lab's reported units, exactly as they appeared on the report. A number read from a document always links back to it; a number typed in by hand is marked as such.

Confidence scoring

Each extraction carries a confidence score and the page it came from. The score orders the review — low-confidence items (image-only PDFs, unfamiliar layouts, ambiguous units) are shown first with a question — but it never commits anything on its own: every value, at every confidence, is staged for the patient to confirm before it enters the record. That rule is enforced on every database write the application makes (the Patient Confirmation Layer), not just in the user interface.

Deferred-items workflow

Every staged item is shown in the patient's review queue, never silently dropped or auto-accepted. The patient sees the extracted value, the source document, the lab's printed text and the platform's proposed concept mapping. They confirm, correct or reject; a connected clinician can only read the queue. Each decision is logged with who made it and when.

Audit logging

Every write, edit and confirmation against the patient record — and a clinician’s reads of it — is written to an internal audit log with the actor, the action, the resource and a timestamp. Patients have a right to request a copy of their own audit log under UK GDPR Article 15.

04

AI usage disclosure.

AI is used to read documents, match terms and describe a patient's own data in plain words. It is not intended to diagnose or to recommend treatment, and it takes no decision about anyone on its own. AI features are disclosed under a standing notice in the product, and the models, and the data each patient-facing feature sends them, are named on the How-we-use-AI page. The disclosure that follows is the plain-English version of what is also captured for EU AI Act Article 50 compliance.

Where AI is used

• ·Document parsing — extracting structured values from uploaded lab PDFs, clinical letters, and images.
• ·Biomarker description — a plain-words account of where a marker sits against the range printed on the report, on the patient's request, under the standing notice that it is AI.
• ·Terminology disambiguation — when scoring can't narrow a SNOMED or LOINC match, the AI proposes the most likely candidate for the patient to review and confirm.
• ·Drug-name classification — which category a recorded medicine belongs to (prescription, supplement, hormone, peptide, vaccine or over-the-counter).

What the platform never does with AI

• ·Nevertrains AI models on patient data ourselves; our AI providers process it under their API data-processing terms, listed on the Security page.
• ·Neveruses AI to make automated decisions about patients within the meaning of UK GDPR Article 22: what AI produces is shown to a person, who decides.
• ·Neverreads a document before the user has given the health-data consent, and never runs the optional AI features (summaries, the assistant) without the user's separate AI consent.
• ·Neverhides that AI is in use: AI features sit under a standing notice in the product, and the How-we-use-AI page names the models and the data each patient-facing feature sends them.
• ·Neversells data, to an AI provider or anyone else.

What the platform always does with AI

• ·Alwaysrecords every AI call in an internal audit log — model name, token counts, consent verification. Patients have a right to a copy of their entries.
• ·Alwaysmarks every AI-generated record in the GDPR data export with an ai_generated flag so the patient can see which parts of their data came from AI.
• ·Alwayskeeps the record usable without the optional AI features: everything you record or confirm is there whether AI is on or off.
• ·Alwaystreats human oversight as the default: AI output is shown to a person beside the record it came from, and is not a substitute for clinical judgement.

05

Reference range handling.

Reference ranges are stored alongside each value. Where a printed range is missing or cannot be used, a general adult range is used and labelled as such. When a Medichecks panel reports HbA1c with a range of 20–42 mmol/mol and an NHS GP panel reports it with <42 mmol/mol, both are preserved with their original framing. The chart shows the patient's value with the range that was actually in effect for that draw, not a retroactively re-applied platform reference range.

UK pathology unit conventions are first-class. Cholesterol is mmol/L by default; testosterone is nmol/L; HbA1c is mmol/mol (with the % equivalent computed on read for comparison with international panels). Vendor-specific reference profiles are stored per lab, so a Randox cardiology panel's slightly different LDL cut-points don't get flattened into one range.

When a marker is reported in units the platform doesn't have a UCUM conversion for, it is preserved as-is and shown on the chart with a unit annotation rather than silently converted. The platform will never invent a value.

06

Identifiers in use.

These are the concrete identifiers that land in the patient record. They are not aspirational examples.

• ·SNOMED CT UK 764146007 — penicillin (substance), used to anchor allergy records.
• ·SNOMED CT UK 372687004 — amoxicillin, a descendant of penicillin in the SNOMED CT hierarchy.
• ·LOINC 4548-4 — haemoglobin A1c / total haemoglobin in blood (HbA1c).
• ·LOINC 718-7 — haemoglobin (mass/volume) in blood.
• ·UCUM mmol/mol ↔ % — HbA1c unit conversion held internally; both forms surfaced on the chart.

← Back to the home page