For health apps · telehealth · clinics
A medical report reader for the whole record, not one page.
Vitrubo reads a medical report of any kind, a lab PDF, a discharge summary, a prescription photo or a scanned sheet, into one structured FHIR R4 record and explains what it found in plain language, with the medical guidance behind every statement. For health apps, telehealth services and clinics it is the reader you embed under your own brand; for the person holding a report, the live reports below show the result.
- HIPAA compliant
- GDPR compliant
- Encrypted in transit and at rest
- HL7 · FHIR R4
A medical report reader that holds to the same standards a hospital does.
LOINC codes
Every value the reader finds in a medical report lands on one reference standard, whichever lab or hospital produced the page. Units are made comparable, so two reports from two years read on one line.
Hospital records read
Roughly 100,000 anonymised hospital records read on premises in a clinical program, through InterSystems IRIS for Health. Nothing left the perimeter.
Stanford MedAgentBench
Every task passed across five runs on the Stanford benchmark for agents that work on medical records.
Native record
One FHIR R4 record per person, every result coded and dated, the source document kept. HIPAA business associate agreement for US deployments, GDPR Article 28 terms and Standard Contractual Clauses as standard.
Who embeds a medical report reader?
The reader sits at a different point of the journey for each product, and the same rule holds in every case: the reader drafts, a professional signs, and the person who owns the report keeps a copy they can read.
Every report a user uploads becomes data.
Users arrive with a folder of PDFs, photos and screenshots. The reader turns each one into a structured record, explains it in plain words, and regenerates the report whenever a new file lands. Embed it, bundle it or resell it under your brand; the user comes back with every new result.
The whole history before the consultation.
Discharge letters, outside lab reports and old prescriptions arrive as paper or scans. The reader reads them into one record, so the clinician opens a timeline instead of a pile, with connected conditions and medications already drawn out.
A medical report explained, not translated.
What stands out, why the flagged values belong together, and what to raise with a doctor, in plain language with the guidance behind each statement one tap away. Educational context to bring to an appointment, not medical advice.
What the medical report reader does with a document.
A lab PDF, a photographed prescription, a scanned discharge summary, an HL7 message or a FHIR bundle from a partner system. The reader recognises the layout, reads the values and the narrative, and files the document automatically. A hospital record that spans several dates becomes one report per date, each in its place on the timeline.
Values, units, reference ranges and flags are computed by deterministic code, never written by a model. Several AI models then read the structured result and cross-check each other; a disagreement is resolved and an omission caught before anything is shown. That split is what makes an online reader dependable enough for a clinician to review.
Everything the reader extracts becomes a FHIR R4 record: results mapped to LOINC, conditions to SNOMED CT and ICD-10, medicines to RxNorm and ATC, units to UCUM. Reports from different labs and years stop being a folder of formats and read as one history, so a value drifting slowly, which looks normal on any single medical report, becomes visible.
The interpretation groups the flagged results into a few connected stories and sorts them into four zones: needs attention, worth watching, back to normal, always normal. Every statement links the named medical guidance it rests on, EHA, WHO, NICE, KDIGO or BSH, with up to 30 sources behind one biomarker view. A chip opens the publication.
A plain-language patient view that says what the report means and what to discuss with a doctor. A clinician view with the full reasoning, the connected conditions and medications, and the tests to consider. Both come from one analysis, so nothing is said to the patient that the clinician has not seen.
The report is not a one-off export. Each new document the reader receives regenerates the interpretation, and previous versions stay as history. Vitrudoc, an AI chat grounded only in the person's own record, answers questions about what the report says and points back to the line it came from.
A year of reports, filed into one record.
Open the live report of a 58-year-old whose follow-up ran across a year: lab reports from several draws, clinic letters and a medication list, each read by the medical report reader and filed into its folder. The record shows which values moved, which returned to normal and which the guidance says to re-test, with the source behind every line. The patient view and the clinician view sit side by side over the same reading.
The reader connects to what you already run.
Embedded in your product.
The reader runs behind your own upload button. Documents flow in as files, HL7 or FHIR; the structured record and the explained report flow back into your app, your EHR or your portal as FHIR and JSON. Your users never leave your brand.
PlatformWhite label, no integration.
A role-based portal for the clinician and the person who holds the report, and branded PDFs, all under your name. No engineering project is needed to begin reading reports.
API first.
Teams with their own front end take the API alone: send a medical report as a file or JSON, receive the structured record and the interpretation as JSON. Recognition, normalisation and interpretation, together or one at a time.
Interface and API, for every customer.
Documents read into FHIR R4, values mapped to LOINC, units made comparable. Containers on your infrastructure or a private cloud; you own the keys.
Why not paste the report into a chatbot?
Because a medical report is not a prompt.
A general-purpose model
- Not designed or validated for medical documents; a general model is a writing tool, not a medical report reader.
- Reads a multi-page scan or a photographed prescription loosely, drops a line or misreads a decimal, and does not notice.
- No normalisation: the same test appears under different names, units and ranges from one report to the next, and stays that way.
- Each report is read on its own; there is no record, so nothing accumulates across visits or years.
- No source behind a statement, so a clinician has nothing to check and the patient has nothing to trust.
A purpose-built report reader
- Document-native reading of PDF, photo, scan, HL7 and FHIR. Numbers are computed by deterministic code, never written by a model.
- A normalisation engine for names, units, reference ranges and LOINC mapping, so a report from any lab lands on the same scale as the last one.
- Several models review the same case; disagreements are resolved and omissions caught before the interpretation is shown.
- Cited, claim by claim: every statement links the medical guidance it rests on. One click opens the publication.
- Built for the record: each new report regenerates the interpretation, previous versions stay as history, and the reader runs inside your perimeter with identity kept out of the prompt.
Every statement rests on named medical guidance. Each chip opens the same guideline page a clinician would read.
From first call to production, on your users' own reports.
An evaluation runs on the documents your users actually upload, not on ours. Six steps, none of them a commitment until the last.
Talk to the team
A short call about the kinds of medical report your users hold, the formats they arrive in and where in your product the reader should sit.
Sandbox and API docs
Test access for your team, with the API contract, sample documents and sample payloads.
Run your own reports
Send real documents, anonymised: lab PDFs, discharge summaries, prescription photos, scans.
Validate the output
Your clinician reviews the structured record and the explained report against their own reading, alone or together with us.
No commitment at this stage
Evaluation is an evaluation. Branding, answer style per audience and capability switches are configured here.
Production when ready
Inside your perimeter or a private cloud, embedded in your app, connected to your EHR, or portal-first.
Questions about the medical report reader.
Any document a person or a clinic is likely to hold: a laboratory report as PDF or photo, a hospital discharge summary, a prescription, a consultation letter, a scanned page from a paper file, or a structured feed as HL7 or FHIR R4. Blood, urine and allergy panels arrive as values; hospital records, prescriptions and notes are read as context for the interpretation. A document that covers several dates is split into one report per date.
A viewer shows the page. The reader reads it: values are extracted and computed in code, the narrative is read as context, everything is mapped to one reference standard and written into a FHIR R4 record. Then the record is interpreted against the person's history and named medical guidance, and explained in plain language. The output is a structured record and a report you can act on, not a rendering of the original.
Every statement the reader writes links to the medical guidance it rests on, so the basis for a claim can be checked rather than trusted. Numbers, units, ranges and flags are computed in code, and several models review the same case with their disagreements resolved before anything is shown. In a clinic or lab deployment a professional reviews and signs. The reader prepares the ground; it does not decide.
No. Vitrubo does not diagnose, does not select or recommend treatment and does not replace a clinician. It reads the medical report, organises the history, explains what stands out and names the tests to consider. For a patient it is educational context to bring to an appointment, not medical advice. The decision stays with the professional.
A plain-language report in four zones: what needs attention, what is worth watching, what has come back to normal and what was always normal. Flagged results are grouped into a few connected stories rather than listed one by one, each with the guidance behind it one tap away. Trends for every marker across earlier reports appear on one line, and Vitrudoc answers questions grounded only in that person's own record.
The same analysis in its clinical form: full reasoning, connected conditions and medications, tests to consider, and the source chip behind each statement. Both views come from one reading, so the patient view never says something the clinician view has not shown. The clinician can switch between them and see what the patient was told.
Photos and scans are converted to pages and read by several vision models in parallel, whose readings are cross-checked against each other before a value is accepted. Values, units and flags are then computed by deterministic code rather than transcribed by a model. Where the readings disagree, the value is not passed through as a confident number.
Yes. That is the main way it is used. It runs behind your own upload button, returns the structured record and the explained report as FHIR and JSON, and can also ship as a white-label portal and branded PDFs under your name. Every new document a user uploads regenerates their report, which is what brings users back to your product with each new result.
Containers run on your infrastructure or in a private cloud, you own the keys, and Vitrubo ships versioned builds with no access to the data. Identity never enters the prompt; models see values and an internal ID, not a name. Data is encrypted in transit and at rest. A HIPAA business associate agreement for US deployments and a GDPR Article 28 processing agreement with Standard Contractual Clauses.
Results are normalised to one standard, 17,000+ LOINC codes for the tests, SNOMED CT and ICD-10 for conditions, RxNorm and ATC for medicines, UCUM for units. A report from one lab in one year and another lab in the next land on the same scale, so the history of a marker reads as a trend rather than as a set of unrelated pages.
Roughly 100,000 anonymised hospital records were read on premises in a clinical program at Assuta Medical Center, through InterSystems IRIS for Health, with nothing leaving the hospital's perimeter. On Stanford MedAgentBench, the benchmark for agents that work on medical records, Vitrubo completed 600 of 600 tasks across five runs.
With a demo call, followed by test access and a sandbox with API documentation. Your team sends its own anonymised documents, the kinds of medical report your users actually hold, and your clinician validates the structured record and the explanation before any commitment. Production follows when you are ready, inside your perimeter or a private cloud.
Demo cases
Invented people, real product. Every case is a synthetic record with a stock portrait: no real patient, no real result. The reports are live.
Robert Hensley
58A year of CKD follow-up with full context supplied.
Emily Carter
34Five visits over nine months with no diagnosis supplied.
Ryan Hayes
30Fifteen months of lifestyle change. The direction of travel is read.
See a medical report read end to end.
Open the live report of a 34-year-old across five visits in nine months, with no diagnosis supplied and every statement carrying its source. Or bring your own documents: a walkthrough on your users' formats, sandbox access for your team, and a read report on your own anonymised files.