About & safety · Built in London

Who we are and how we think about safety.

biomarkr is a health intelligence platform built to help people understand their blood test results over time. This page explains what we are, what we are not, and the principles that govern how the platform works.

Non-diagnostic toolClinician-reviewed clinic workflowPseudonymous data handlingBuilt in London
Why this exists

Built from
lived experience.

F
Founder, biomarkr
Built in London

biomarkr was built after years of trying to make sense of repeated blood tests during a long personal health journey. Test after test, the results came back — numbers, ranges, flags — but the picture never became clear.

"I was taking screenshots of my results. Saving PDFs. Opening them side by side at each new appointment, trying to remember whether a number had been higher six months ago — and whether that actually mattered."

Eventually things became clearer. But the experience made one thing obvious: the hardest part of blood testing is not getting the results. It is understanding what they mean across time, across your body systems, and in the context of how you actually feel.

Private blood testing in the UK is growing fast. The interpretation infrastructure around it is not keeping pace. Patients often leave appointments with numbers but little sense of direction. Clinicians spend time re-explaining things a clear report could communicate once.

biomarkr exists to close that gap — not to replace clinicians, but to give patients and their doctors a longitudinal picture that makes those conversations more informed and more useful.

What we believe

The principles that shape everything we build.

These are not aspirations. They are constraints that govern product design, output framing, and what the platform will and will not do.

02
Clarity without overclaiming.
The interpretation layer must be honest about what it knows and what it does not. biomarkr will not state certainty when the data is ambiguous.
03
The clinician remains in control.
biomarkr generates interpretation drafts. Clinicians review, edit, and approve clinic reports before they reach patients.
04
Explanation supports agency.
Understanding results should not require blind trust. Outputs can trace reasoning back to the structured data inputs that produced them.
05
Safety is structural, not aspirational.
Language constraints, banned phrase filters, fact verification, and clinical contract validation are automated systems designed to catch and constrain unsafe outputs before they reach the user.
06
Private data is handled with discipline.
biomarkr does not need to know who clinic patients are to produce useful intelligence. The pseudonymous model limits the sensitivity of what biomarkr holds.
Scope & limits

A clear statement of what biomarkr is.

These boundaries are not caveats added at the end. They are the design brief.

biomarkr will
Provide longitudinal interpretation of biomarkers and body-system trends over time
Surface cross-system patterns that may be worth clinician review
Produce evidence-aware next-step prompts and retest discussion points for clinician review
Make uncertainty explicit when data is insufficient or a result is ambiguous
Explain what a blood panel can and cannot tell you, including what is missing
Encourage users to discuss concerns with a qualified clinician
biomarkr will not
Diagnose medical conditions or claim diagnostic accuracy for any output
Provide treatment instructions, prescribe medication, or tell users to start or stop supplements without clinician input
Replace clinical judgment or act as a standalone clinical decision-maker
Perform autonomous clinical triage or prioritise care decisions without clinician involvement
Use alarmist or diagnosis-adjacent language in patient-facing outputs
Store patient names, NHS numbers, or contact details in the clinic workflow
Safety architecture

Safety is built into the pipeline.
Not added at the end.

Every report passes through automated layers before it reaches a clinician for review. These deterministic systems run separately from the AI layer.

The core design principle is straightforward: facts first, AI second. biomarkr extracts and structures every biomarker — name, value, unit, reference range, previous result, and trend direction — before interpretation is generated. It does not generate final interpretation directly from raw PDF text; the document is first converted into structured biomarker data.

Once a draft is generated, automated controls check that the narrative is grounded in the panel data, free of alarmist or diagnostic language, internally consistent, and appropriately caveated.

In the clinic workflow, the output is then reviewed and approved by the clinician before it reaches the patient. Nothing is delivered autonomously. The human-in-the-loop is structural, not optional.

The automated acceptance gate runs 28 test scenarios — across four patient profiles and seven test timelines — before every release. All 28 must pass.

Report pipeline28/28 checks passing
1
Data extraction & structuring
Biomarkers extracted from PDF or manual entry. Each validated before processing continues.
2
NarrativeControl — pre-generation
Defines which systems may be flagged, which biomarkers may be named, and what claim language is permitted.
Deterministic guardrail
3
Interpretation generation
System scores, trend analysis, cross-system patterns and narrative drafted under constraints.
4
NarrativeLinter — post-generation
26 banned phrase patterns checked and replaced before the draft moves forward.
Deterministic guardrail
5
Clinical Contract Validator
Five violation types checked. Where possible, violations are corrected deterministically before Stage 6.
Deterministic guardrail
6
Clinician review & approval
Clinician reads, edits where needed, and approves. Nothing reaches the patient without explicit sign-off.
Human in the loop
Deterministic, not probabilistic
The safety checks do not rely on AI self-correction. If a violation is found, it is corrected deterministically where possible, and the corrected draft still remains subject to clinician review in the clinic workflow.
Tested before every release
The automated acceptance gate runs across 28 test scenarios — four patient profiles, seven timelines each. All 28 must pass before release.
Explicit about what it doesn't know
If a panel is missing markers that would improve interpretation confidence, the report says so. Confidence levels are shown, not hidden.
Read a full technical explanation of how biomarkr thinks →
Data & privacy

Designed to hold as little as possible.

The pseudonymous data model is a deliberate architectural choice to minimise the sensitivity of what biomarkr processes.

How the pseudonymous model works

In the clinic workflow, biomarkr never receives patient names, NHS numbers, date of birth, or contact details. Your clinic assigns a pseudonymous ID, and biomarkr processes only that ID alongside blood test data.

The mapping between a patient's identity and their pseudonymous ID lives entirely within your clinic's systems. biomarkr cannot reverse it.

For patients using the direct companion app, biomarkr holds account credentials and uploaded test data under UK GDPR. A full privacy policy is available on request.

What biomarkr holds — clinic workflow
Patient name
Not stored or processed
Never
NHS number
Not stored or processed
Never
Contact details
Not stored or processed
Never
Patient ID
Pseudonymous reference — assigned and held by clinic
Clinic holds link
Biomarker data
Values, units, ranges, trend history
Processed
Report content
Generated interpretation, approval status
Stored
Data security
All data is encrypted in transit and at rest. Access to production systems is restricted. No third-party advertising or analytics platforms have access to health data.
Regulatory positioning

Operating in the intended safe lane.

biomarkr is positioned as a health intelligence and interpretation tool — not a medical device. Staying inside that line is central to how the platform is built.

In the UK, software intended to diagnose, prevent, monitor, treat, or alleviate a medical condition may qualify as Software as a Medical Device and fall under MHRA regulation. biomarkr is currently designed and positioned to remain outside diagnostic or autonomous clinical decision-making use cases.

The intended safe lane
biomarkr provides longitudinal interpretation, system-level signals, evidence-aware next-step prompts, and explicit uncertainty. It does not diagnose, prescribe, or make autonomous clinical decisions. This is the intended operating lane we are designing around in the UK regulatory context.

Every new feature is evaluated against these boundaries. If a feature moves the product toward autonomous clinical decision-making, it is not built in that form.

In the clinic workflow, clinician review is the mechanism that keeps the product in its intended lane. The AI generates a draft. A qualified clinician reviews and approves it.

We are monitoring developments in UK health AI regulation and will engage with regulatory guidance as the platform evolves. We are not currently seeking SaMD certification and will not make regulatory claims beyond what has been formally established.

In practice
No diagnostic claims
biomarkr outputs describe observations in the data — not clinical diagnoses.
In practice
No autonomous triage
Review prompts help clinician focus. They do not substitute clinical prioritisation.
In practice
No prescribing or treatment direction
Next-step prompts are discussion points, not instructions for independent action.
In practice
Always routes to a clinician
Patient-facing outputs encourage discussion with a GP or clinician when anything is concerning.
Honest about limitations

What biomarkr cannot do.

We believe trust is built by being precise about what a tool is for — and honest about where it falls short. These are not edge cases. They are structural limitations users and clinicians should understand.

01
Cannot interpret symptoms alone
biomarkr works with biomarker data. Symptoms enrich interpretation when logged, but the platform does not assess symptoms independently.
02
Cannot replace clinical examination
Blood results are one input. Clinical examination, history, medication context, and other factors remain essential.
03
Cannot guarantee cross-lab accuracy
Different laboratories use different reference ranges and units. Comparisons across labs should be interpreted with care.
04
Longitudinal patterns need multiple tests
A first upload produces a baseline. Trend analysis improves with each additional test.
05
Not designed for rare presentations
Rare presentations or complex multi-system conditions may not be well-served by pattern-based interpretation.
06
AI-generated text can contain errors
Safety checks reduce risk materially. No system eliminates it entirely. Clinician review exists because human oversight is essential.
Get in touch

Questions about safety,
data, or how we work.

If you have questions about how biomarkr handles data, how the safety architecture works, or how to evaluate the platform for clinical use, we are happy to talk through it properly.