Can you extract lab results from PDFs with an LLM? Yes. This guide explains what sits between a working prototype and a production system, and how to decide whether to build it or buy it.
Can a general purpose large language model extract lab results from a PDF? Yes, it can. If you give a modern LLM a clean laboratory report and ask for the results as JSON, you will usually get something that looks right within a few seconds. A capable engineer can turn that into a working prototype over a weekend.
The harder question is what it takes to go from that prototype to a system you would trust with thousands of real reports, from many laboratories, feeding a product that people make health decisions with. That distance is larger than it appears, and it is the subject of this guide.
We write this with some humility, because we underestimated it ourselves. Jonda Health began by building a patient-facing health record. Building it showed us that the layer underneath, turning documents into reliable and standardised data, was far deeper than we had allowed for. That layer became JondaX. This guide shares what we learned, and it is intended to help you make the decision that is right for your team, including the cases where building it yourself is the right call.
The prototype succeeds because it is tested on the easy case. The report is usually a digital PDF from a major laboratory, the layout is tidy, the language is English and someone is looking at every output. Under those conditions an LLM performs very well, and it is natural to conclude that the problem is mostly solved.
Production looks different in three ways. The documents become messier: scans, phone photographs, faxed copies, multi-page cumulative reports and layouts nobody has seen before. The volume means nobody is checking each output by eye. And the consequences change, because a wrong value is no longer a bug in a demo. It is a number in someone's health record.
In our experience the first 80% of accuracy arrives quickly and cheaply. Most of the time, cost and risk sit in the remainder.
The LLM call is one component. A production system surrounds it with everything needed to make its output safe, consistent and usable. When you budget for an in-house build, you are budgeting for all of the boxes below, along with the monitoring that watches over them.
The prototype is the second box. The seven areas below describe the work in the others.
A traditional OCR system fails visibly, with garbled characters that are easy to spot. An LLM tends to fail plausibly. When part of a scan is unreadable, it may supply a value that looks reasonable. In a dense table it may attach a value to the neighbouring test, or pair a result with the wrong reference range. The output is well formed JSON either way, which is what makes these errors dangerous. An in-house build needs an independent layer of validation: checks that values are physiologically possible, that units belong to the test, that every extracted number can be found in the source, and that uncertain cases are flagged for review and never guessed.
Extraction gives you the words on the page. Your product almost certainly needs the concept behind them, so that "HbA1c", "Glycated haemoglobin" and "Hemoglobina glicosilada" become one trend line. An LLM can suggest a mapping, but suggestions are inconsistent and sometimes confidently wrong, particularly where specimen or method changes the meaning. Reliable mapping to medical coding standards, or to your own catalogue, depends on a maintained knowledge base with clinical oversight, and the same is true for unit conversion, which has to be correct for each specific analyte. This is long-term work and it does not fit inside a prompt.
The same document sent twice can produce two slightly different outputs. Model providers update and retire model versions, and a prompt that worked well in March may behave differently in September. To manage this you need a fixed test set of real reports with verified answers, automated regression testing every time the model or prompt changes, versioning of both, and monitoring for drift in production. Teams often discover this only after an upgrade quietly changes their results.
A laboratory report carries a name, a date of birth, identifiers and clinical results. Sending that document to a third-party model means a data processing agreement, clarity on where the data is processed, confirmation that it is not used for training, and a lawful basis for any cross-border transfer. Consumer versions of AI tools are generally not appropriate for identifiable patient data, yet that is often where prototypes begin, and habits formed in a prototype have a way of reaching production. Many teams conclude that identifiers should be removed or pseudonymised before any model sees the document, which is a further component to build and verify.
The cost of one prototype call is negligible, which makes it easy to underestimate the cost of production. Scanned pages are sent as images, and images consume far more tokens than text. A reliable pipeline rarely makes one call per document. It may extract, then validate, then map terminology, and it retries when a check fails. A four-page scanned report processed in three passes becomes twelve or more model calls, and a long cumulative report multiplies that again. Teams that route every task to the largest available model, where a smaller model or plain code would do, often find that their cost per document is several times what they planned for. Token efficiency is an engineering discipline of its own, and it takes time to learn.
Some results will always need a person to look at them. Someone has to decide whether an ambiguous test name maps to one concept or another, verify a sample of outputs every week, and investigate when a customer questions a number. That person needs clinical or laboratory knowledge, a tool that shows the source next to the extracted data, and a process for feeding corrections back into the system. If nobody on your team has that background today, this becomes a hire, and it continues for as long as the product runs.
Laboratories change their report layouts without notice. New customers bring new laboratories, new languages and new test panels. Coding standards publish updates, and models are deprecated. An extraction pipeline is therefore a product with a roadmap, and it needs an owner. It is worth asking who that owner will be in two years, and what happens to the pipeline if the engineer who built it moves on.
The table below is illustrative, and your own figures will depend on your scope and market. Its purpose is to make sure the comparison with a vendor's price is a fair one, because the API bill is usually the smallest line.
Neither column is free of risk. Building leaves you dependent on a model provider and on the few people who understand the pipeline. Buying leaves you dependent on a vendor, which is why the due diligence matters.
There are situations where an in-house build is the sensible decision, and it would be misleading to suggest otherwise.
Building makes sense when your scope is narrow and stable, for example one or two laboratories sending digital PDFs in a single language with a layout that rarely changes. It makes sense when extraction is the heart of your product and the thing you intend to be better at than anyone else. It makes sense when you already have clinical informatics expertise on the team and engineers with time to own the pipeline for the long term. It can also be the only option where regulation requires everything to run inside your own environment and no vendor can meet that requirement. Finally, it is reasonable where the downstream use tolerates error, such as an internal analytics project where a person reviews the conclusions.
Buying tends to be the better decision when the opposite conditions hold. Your reports come from many laboratories, in several languages, as scans and photographs as well as PDFs. The data feeds something clinical or patient-facing, where an error has consequences. You need output in a standard such as FHIR, mapped to medical coding standards or to your customers' own code sets. Your engineering team is small, and every month spent on extraction is a month not spent on the product your customers are paying for. In those circumstances the question is rarely whether your team could build it. They probably could. The question is whether it is the best use of them.
The decision does not have to be all or nothing. Many teams buy the extraction and harmonisation layer and build everything that makes their product distinctive on top of it: the insights, the user experience, the clinical workflows.
If you are unsure, run both options against the same evidence. Assemble 100 to 200 of your own real reports, including the difficult ones, with verified answers. Run your prototype and one or two vendors against that set, and score them on the same criteria. Our companion guide, How to Choose a Lab Report API: 12 Things to Test Before You Integrate One, provides a scorecard for exactly this purpose, and it works just as well for evaluating your own build as it does for evaluating a vendor.
Work through these questions together. If most of your answers fall in the middle column, building is a reasonable path. If most fall in the right-hand column, buying is likely to serve you better.
JondaX is the health data transformation engine built by Jonda Health, and JondaX for pathology data is a lab report API. You send it a laboratory or pathology report as a PDF, a scan or a photograph, and it returns the results as structured, standardised data through a documented API.
JondaX uses AI to do this work, so the choice in this guide is not between AI and something older. The difference lies in who carries the work that surrounds the model. With JondaX, the areas described above are part of the service: validation of extracted results, resolution of the different ways the same test is captured, unit normalisation, mapping to medical coding standards or to your own code set, and clinical review and quality assurance by Jonda Health's own team. It reads reports in more than ten languages, and returns results as JSON, FHIR, HL7 or CSV. To date it has processed more than 500,000 files and more than 26 million data points.
Jonda Health is ISO 27001 certified, and JondaX is designed to comply with HIPAA, GDPR and PDPA. Developers can sign up and start on a self-serve basis, and teams building with AI agents can call JondaX directly through the JondaX MCP server.
If you already have a prototype, the most useful next step is a fair comparison. Run the same set of your own reports through your prototype and through JondaX, and let the results inform the decision. Try JondaX or get in touch with our team, and we will gladly help you set up the test.
Yes. A modern LLM can read a clean laboratory report and return the results as structured data. The difficulty lies in doing so reliably across scans, photographs, many layouts and several languages, and in detecting the cases where the model is wrong.
It depends heavily on the documents. Accuracy on clean digital PDFs is typically high, and it falls on poor scans, dense tables and unfamiliar layouts. The only figure that matters is the one you measure on your own reports, at the level of individual fields, with clinical correctness checked as well as transcription.
It can be, under the right conditions. You generally need a data processing agreement with the provider, clarity on where the data is processed, confirmation that it is not used for model training, and a lawful basis for any cross-border transfer. Consumer versions of AI tools are generally not suitable for identifiable patient data. Your own legal or compliance adviser should confirm what applies in your jurisdiction.
A prototype can take days. A production-grade system, with validation, terminology mapping, review tooling, monitoring and compliance in place, commonly takes several months and then needs ongoing ownership.
The model fees are usually the smallest part. The larger costs are engineering time, clinical review, maintenance and compliance. At volume, token costs also rise faster than most teams expect, because scanned pages are processed as images and reliable pipelines make several calls per document.
Yes. JondaX for pathology data is a lab report API from Jonda Health. It accepts laboratory and pathology reports as PDFs, scans and images in more than ten languages, and returns structured results mapped to medical coding standards or to your own code set, in JSON, FHIR, HL7 or CSV.
Suhina Singh is the founder and CEO of Jonda Health, a Singapore-based health data infrastructure company. A physician by training, she works with health systems across Asia-Pacific to harmonise, de-identify and standardise clinical data so it can be trusted and used. Jonda Health is ISO 27001 certified.
