The record, as it stands
Current diagnoses, medication, what changed since the last visit, what has been flagged — pulled from the source systems over FHIR.
Clinexus
from your designs to a pilot
your clinicians can use
How we read the product, how we would build it,
and what each phase takes.
Pilot · August 2026
Clinexus V1.0 · January 2027
EU MDR Class IIa
The product as we understood it
One screen, before the door opens
A general physician has a few minutes before a patient walks in, and the record system was not built for those minutes. Clinexus assembles the patient into one screen — read from the record, never written back to it.
Every fact with its origin
Source and date travel with each value. A clinician can see where a number came from and how old it is without leaving the screen.
An assistant bound to the record
It answers from the patient's data, cites what it used, and abstains when the record does not support an answer.
It does not write back
Alerts are read from the source system, not computed here. "Start Visit" and "Reschedule" stay local. Referrals are read-only.
This is the reading your answers of 28 July put us on, and every figure later in this deck rests on it. Where your designs point somewhere else, we have said so — in the scope document rather than in week six.
02How it is put together
The same four layers in both phases
The pilot and V1.0 are not two products. They are the same shape, with V1.0 adding services underneath the screens rather than replacing them.
The application
The day's list, the patient overview, the assistant. This is where the pilot's weight sits — most of its effort is here.
The service behind it
Assembly, provenance, session and audit. It owns the rule that a fact never loses its source.
The clinical seam
The assistant and the model sit behind one interface from day one, so the model can be swapped, pinned or moved inside a boundary without touching the screens.
The source port
One internal interface, adapters behind it. FHIR stops at the port; nothing above it knows which system the data came from.
Why this matters for the estimate. The pilot buys layer 1 over a single synthetic source. V1.0 buys the depth of layers 2–4 — which is why it costs several times the pilot while looking, on screen, much the same.
03Architecture & deployment · the pilot
The pilot — four layers over one synthetic source
Nothing in it waits on access to a system somebody else controls. That is what makes August reachable.
04Architecture & deployment · Clinexus V1.0
V1.0 — the same screens over real depth
Ingestion, adapters, aggregation, an inference runtime inside Finland, and a regulatory file. Most of what is added renders nothing on screen.
05What runs the AI, and where
Your hosting answer decides more than it looks
Self-hosted inference in Finland means the model must be one we can download, pin to a fixed version and run inside your boundary. That rules out every hosted-only model — including most of the names at the top of today's leaderboards.
Chosen by two cheap filters, then measured
Licence first — several widely used families carry acceptable-use terms that read badly against a clinical device. Then serving size: one clinic of GPs is a modest load, and a single continuously running GPU in a Finland region — of the order of €800 a month at today's prices — covers it.
That is a third-party running cost rather than anything we charge, and it is worth carrying into your funding conversations as such.
Two named Finnish-capable paths
A Nordic medical model that deploys as a container inside your boundary, or a Finnish healthcare specialist already used in wellbeing-services counties, processed in the EU.
Which one fits depends on how strictly self-hosting binds the speech component.
None of this is on the critical path
The pilot runs on synthetic data, so residency does not bind it and the model can be an external service. The Finland runtime is bought before the first identified patient record exists — not before August.
One question back to you. Your answer says self-hosted in Finland. We would like to hear what self-hosted means on your side — a container in a Finnish region, a machine you own, or a Finnish provider under contract. The three have different costs and different technical-file consequences.
06Why we would start with the pilot
You already described what the pilot is for
A first version, focused on the frontend and on usability testing, run with the doctors who made your synthetic data, on a tight timeline. We agree — and that is exactly the shape we have costed.
- 1It answers the one question no document can. Whether clinicians reach for this in the few minutes they actually have. Architecture cannot settle it; a doctor with the product in front of them can.
- 2It is the artefact your investors can see. A working product used by real clinicians is a different conversation from a deck and an estimate.
- 3It buys the answers V1.0 is waiting on. The open questions are almost all V1.0 questions. Running the pilot and closing them can happen in the same weeks instead of one after the other.
Resolving everything first is a discovery phase
Working the full question list to the bottom before starting would take at least two weeks of both our teams — and August is the month you wanted the pilot in.
We would rather start on what is already settled and close the rest alongside it.
Very little, and none of it blocking
Synthetic data in FHIR R4, which you have. One or two hours with a clinical lead at kickoff. A decision on dictation. Nothing that waits on funding or on system access.
07Your pilot · August 2026
This is what August buys
A working product on synthetic data, in front of your doctors — not a prototype and not a click-through.
- The day's appointments, with the alert tiles read from the source
- Graceful behaviour when data is missing, stale or contradictory
- The patient overview — every fact carrying its source and its date
- Sign-in, session and audit logging
- Check-in vitals, and referrals shown read-only
- A standards-compliant synthetic environment to run it all against
- Ask-AI: grounded in the record, citing what it used, abstaining when it cannot answer
- One or two hours with your clinical lead, to set the data-handling defaults
| Who is on it | Hours | FTE | W1 | W2 | W3 | W4 | W5 |
|---|---|---|---|---|---|---|---|
| Backend and integration | 180 | 0.90 | 40 | 40 | 40 | 40 | 20 |
| Frontend | 125 | 0.63 | 25 | 25 | 25 | 25 | 25 |
| QA | 85 | 0.43 | 15 | 15 | 15 | 20 | 20 |
| Project manager | 75 | 0.38 | 15 | 15 | 15 | 15 | 15 |
| Platform and DevOps | 32 | 0.16 | 20 | 12 | · | · | · |
| Architect · SA/TL | 25 | 0.13 | 5 | 5 | 5 | 5 | 5 |
| The team | 522 | 2.61 | 120 | 112 | 100 | 105 | 85 |
Five weeks, twenty-five working days, 2.6 full-time equivalents. Hours per role per week rather than one number, because the shape is the part you can check — and frontend is what paces this phase. We can start now: nothing in the pilot depends on the questions still open for V1.0.
08Clinexus V1.0 · January 2027
V1.0 — an orientation figure, bought a tranche at a time
A single number here would be useless to you: it would be one you cannot act on until the whole round has closed. So it is cut into five parts, each of which delivers something that works on its own.
| Tranche | What it buys | Person-days |
|---|---|---|
| Product | The application itself — screens, assistant, notes, oversight, localisation, administration | 136–217 |
| Integrations | Adapters to your source systems, clinic identity, and the discovery that has to run against a real one | 26–44 |
| Finland AI runtime | The self-hosted model and speech recognition, and the Finland-resident environment they run in | 46–73 |
| Discovery | Answers bought before the work they gate. Decline any of them and the assumption it would have replaced stays yours | 7–8 |
| Regulatory | Our contribution into the technical file you own — hazard analysis, the evaluation gate, the software inventory | 29–47 |
| Clinexus V1.0 | 243–388 |
Read this as an orientation, not a commitment. Three of the five parts depend on answers nobody has yet — which source systems, which FHIR profile family, whether ESKO is available. Fixing a price against unknowns means pricing the unknowns, and you would be paying for our uncertainty. The range narrows as the open questions close, and those are what the accompanying material is for.
09What we need from you
Four confirmations, and one decision
None of the four needs a meeting. The decision is whether August still holds.
- 1The divergences between your designs and your answers. For each, tell us which of your two documents we should follow. Most are quick; a couple need a word with your regulatory partner.
- 2Which FHIR resource carries an alert raised in the source system. Our reading is that alerts are read rather than computed — and if nothing publishes them, the With Alerts tile is empty in production.
- 3Which FHIR profile family applies — Finnish national, Kanta, US Core, or the LAMK set. This has the widest single effect on the integrations tranche.
- 4The January reading, with your regulatory partner. Controlled deployment with the certification track continuing, which is how we have planned it.
And the one question for this call
Does August still hold on your side, and are you in a position to start the pilot now? We are — the pilot has no dependency left that we control.
The detail sits alongside this deck
Everything we read, every divergence with the evidence on both sides, and the screens your designs imply but do not draw — kept out of this call on purpose, sent as material you can read at your own pace.
light-it.net
10