A biomarker testing platform for the product you are building.

For anyone building a biomarker testing product without building the reading engine. A health app or telehealth service that wants to offer a biomarker test to its users. A longevity or wellness brand that sells a panel under its own name through a lab partner. A laboratory that wants a consumer or corporate line around results it already produces. A clinic that wants its patients to read their own results between visits. And, through any of them, the person who holds a result and wants to understand it. Vitrubo is licensed to the business and delivered under its brand; there is no self-serve signup.

Any format a result takes. A lab PDF, a photo of a printed report, an HL7 message from a LIS, a FHIR R4 bundle from an EHR or EMR, or JSON through the API. Blood, urine and allergy panels arrive as values. Hospital records, prescriptions and notes are read as context, so a biomarker that a medication is known to move is read with that in mind. Numbers, units, ranges and flags are computed by deterministic code, never written by a model, so what the lab reported is what the record holds. Each document is kept beside the values read from it, so the source of any number can be opened.

One FHIR R4 record per person, with every biomarker test result mapped to LOINC and every unit to UCUM, and an interpretation with the guidance it rests on. Through the API this is JSON, ready to render in your own screens. Through the white-label option it is a role-based portal and PDFs under your brand. Both carry the same two views: a plain-language view for the person and a clinician view with the full reasoning, connected conditions and medications, and tests to consider. FHIR and JSON also flow back into the LIS or EHR the results came from.

Through the channels those systems already speak. A LIS sends results as HL7 or FHIR R4 and receives the drafted reading and the follow-up test back the same way. An EHR or EMR exchanges FHIR R4 documents. Your app talks to the API: it posts an upload or a payload and receives the structured record and its interpretation as JSON. The sandbox, the API contract and sample payloads in PDF, HL7 and JSON are part of the evaluation, so your engineers see the integration before anyone commits. A product that starts portal-first and moves to the API later changes the door, not the record.

By putting every biomarker on one scale. Labs name the same biomarker differently, report it in different units and publish their own reference ranges. Each value is normalised to one of 17,000+ LOINC codes and each unit to UCUM, so a biomarker test from one lab partner in one year and another the next reads as points on one line. Reference ranges are kept per laboratory rather than replaced, because the range that applies to a value is the one the lab that measured it published. A product can change lab partner, or accept results a user brings from elsewhere, without starting a second history.

In two parts that are kept apart. The numbers, units, ranges and flags are computed by deterministic code, so the same result gives the same values every time. The reading is drafted by several AI models that cross-check each other, with disagreements resolved and omissions caught before a draft is shown, and every statement links to named medical guidance: EHA, WHO, NICE, KDIGO and BSH among others, up to 30 sources behind one biomarker view. A chip opens the publication. Your medical reviewer checks the basis rather than trusting the prose, and nothing in the report is asserted without a source that can be opened.

Not a table of pass and fail. Flagged biomarkers are grouped into a few connected stories and placed in four zones: needs attention, worth watching, back to normal, always normal. For each biomarker the trend across tests sits beside the latest value and its range, with the guidance behind the interpretation one chip away. Where a repeat is worth considering, the biomarker to re-test and the interval are named. Vitrudoc, an AI chat grounded only in that person's own record, can answer questions beside the report. The same report is available as a PDF under your brand, for the user who wants to bring it to an appointment. The Emily Carter live report shows five results read this way.

The report regenerates against the whole record, not only the new biomarker test. A value that has come back into range since the last test is named as such, a value that has never moved is said to be steady, and a new deviation is read beside the earlier ones rather than on its own. Previous versions of the report stay as history, so what the user read after the last draw can be revisited after the next. For a product this is the mechanism that brings a user back after every test. It runs the same whether the result came from the lab's feed, from an upload in your app or from a hospital record the user added.

No. Vitrubo performs no laboratory testing and sells no biomarker test of its own. The testing is done by your lab partner, or by your own laboratory if you are one. Vitrubo is the platform layer that turns those results into the product: reading, normalisation, interpretation and delivery. Where a page or a product describes a biomarker test, the test is the lab's and the reading is Vitrubo's. The platform is licensed to the business that owns the product; access is by invitation after an evaluation on your own anonymised results, and there is no published price list.

No. Vitrubo is not a diagnostic device, does not select or recommend treatment and does not replace the clinician or the lab scientist. It drafts a reading of the results that are there, organises the record and names tests worth considering; where a professional is involved, the professional reads and signs. For a person reading their own biomarker test in your product it is educational context to bring to an appointment, not medical advice, and the report says so.

In containers on your infrastructure or in a private cloud that you control. You own the keys. Vitrubo ships versioned builds and has no access to the data. Identity never enters the prompt: the models see values and an internal ID, never a name. A HIPAA business associate agreement for US deployments, a GDPR Article 28 processing agreement and Standard Contractual Clauses, encryption in transit and at rest. Roughly 100,000 anonymised hospital records have been read this way on premises in a clinical programme.

Yes. The API returns the FHIR R4 record and the interpretation as JSON, and your app renders it in its own screens; the platform stays invisible to the user. Recognition, normalisation and interpretation can be taken together or one at a time, so an app that already structures its data can take interpretation alone. The white-label portal and PDFs are there for teams that would rather not build screens, and the two can be mixed: API for the app, portal for the clinician. Either way the record stays in your containers under your keys.

The record, the reasoning and the version. The record: one FHIR R4 record per person, with every biomarker test result coded and dated, and its source document kept. The reasoning: every statement carries the named guidance it rests on, so the basis of any sentence a user read can be opened. The version: previous reports stay as history and the platform ships as versioned builds. Together with the data processing agreements, this is what a partner's due diligence usually asks for.

Yes, through an app, brand, lab or clinic that offers Vitrubo under its own brand. The person uploads the PDF or a photo of the biomarker test and reads the plain-language view: what stands out, why it is grouped that way, and what to discuss with a doctor. Earlier tests uploaded alongside are read into the same history, so one test is read on its own and several are read as a line. Vitrudoc can answer questions about the result, grounded only in that person's own record. The reading runs inside the product the person is already using; there is no separate signup with Vitrubo.

With a call about the product you are building, then sandbox access and API documentation. Your team runs its own anonymised biomarker test results, ideally repeat tests from the same people and from more than one lab, and your medical reviewer validates the drafts against their own reading while your engineers check the JSON against your screens. There is no commitment at that stage. Production follows when you are ready, in containers inside your perimeter or a private cloud, connected to the LIS, the EHR or your app.