A prototype that reads a lab report with a large language model takes an afternoon. A system that reads every member's health check, accurately, safely and affordably, takes much more. Here is what sits under the surface.
Reading member health records means turning the health check reports, lab PDFs and device photos members upload into structured, trustworthy data a wellness platform can use. Extraction is only the first of nine capabilities a production system needs, which is why the build or buy decision deserves careful thought.
Most wellness platforms reach the same point. Members are uploading health check reports, device photos and lab PDFs, and the team needs that information as data: to issue rewards, personalise coaching and report outcomes to insurer and employer clients. Someone on the engineering team tries a large language model on a few sample reports, the results look impressive, and the natural question follows. Why not build this ourselves?
Sometimes building is the right answer. More often, the prototype hides most of the work. Reading the document is the visible part. Making the result accurate, consistent, reviewed, private, affordable and maintainable across thousands of providers and dozens of layouts is the part that takes the time and money, and it never really ends.
This guide is written for chief technology officers, heads of product and engineering, and founders at wellness platforms and corporate wellness companies. It sets out nine things a production system needs, what teams tend to underestimate about each, and how to decide whether to build or buy. It complements our broader guide, Extracting Lab Results From PDFs With an LLM: Build or Buy?, with a focus on the full health check that wellness programmes receive.
Figure 1. A prototype proves the tip. Production needs everything underneath.
Member uploads include clean digital PDFs, scanned pages, phone photos taken at an angle in poor light, screenshots from clinic apps and, occasionally, handwritten forms. They arrive in many languages, sometimes several on one page. A model that handles a clean English PDF well can stumble on a skewed photo of a Thai lab report or a two-column layout with merged cells.
A wellness health check is not only a lab report. It includes the doctor's summary, vitals sheets, electrocardiogram (ECG) reports, imaging impressions, vision and dental checks, and photos of home blood pressure monitors and glucometers. Each has its own structure, and the most useful information is often in free text rather than tables.
Extracted text is not yet usable data. The same test appears under dozens of names and abbreviations, in different units, with different reference ranges, and in different languages. Your rewards rules, coaching logic and client reports all need one consistent meaning for each measure. That requires a data model, mappings to medical coding standards, careful unit conversion, and a way of handling the cases that do not fit.
No automated system reads every health record correctly. When values drive rewards, coaching and insurer reports, uncertain readings need checking by people who understand what they are looking at. That means recruiting clinically trained reviewers, ideally covering the languages your members use, building review tools and workflows, setting quality standards and managing peaks in volume.
Reviewers will correct the same kinds of errors again and again unless corrections feed back into the system. New clinics, new report layouts and new test names appear every month. A production system needs a way of turning corrections into improved future processing, and of catching new layouts before they cause errors at scale.
The name on a clinic report may be spelled differently from your member record, written in another script, or ordered differently. Identification numbers are often missing and dates of birth appear in several formats. Duplicate uploads, family members' reports and old reports resubmitted for points all need to be caught.
Health records are among the most sensitive data a platform handles. Sending them to a general-purpose model provider raises questions about where data is processed, whether it is retained or used for training, and whether that is consistent with what members agreed to and with local law. Insurer clients will ask about certifications, data residency, pseudonymisation and audit trails during procurement.
The cost of a single model call looks small. Real costs include repeated calls for difficult documents, reprocessing when prompts or models change, the infrastructure around the model, reviewer time, and the engineering hours spent on fixes. The meaningful measure is the cost per usable record: what it takes, in total, to turn a member upload into data you can trust.
Figure 2. The model call is usually the smallest part of what a usable record really costs.
A health record pipeline is never finished. Models are updated or retired, providers change their report templates, clients ask for new data types and new markets, and the engineers who built the first version move on. Someone has to own monitoring, upgrades, new sources and incident response for as long as the platform runs.
The right answer depends on what makes your platform different.
Building can be the right choice when reading health records is central to what makes your product different, your sources are few and predictable, and you already have clinical and data operations teams who can own it. Buying usually makes more sense when members use many providers across several markets and languages, when you need clinical review and compliance in place quickly, and when your team's time is better spent on the experience members and clients see. Many platforms combine the two: they buy the health data layer and build their own coaching, rewards and reporting on top.
Speed matters more than it first appears. One digital health startup that chose JondaX for all its clinical data reached a working product in around two months, after estimating that building the same capability itself would have taken more than a year and a half. The time saved went into the features its customers actually saw.
Build when reading health records is your core differentiator, sources are few and stable, and you already have clinical reviewers. Buy when members use many providers, formats and languages, when clients need compliance quickly, and when engineering time is better spent on member-facing features.
A large language model can read many clean lab reports well, but accuracy drops on photos, unusual layouts and mixed languages, and plausible output is not the same as verified data. Production systems add consistent mapping, uncertainty detection and clinical review.
Beyond model calls, costs include reprocessing, infrastructure, clinically trained reviewers, engineering upkeep as models and report layouts change, and privacy and certification work. The useful measure is the total cost per usable record at your expected volumes.
Cost per usable record is the total cost of turning one member upload into data you can trust, including model use, retries, review time, infrastructure, engineering and compliance, divided by the number of records that come out usable.
No automated system reads every record correctly, and errors in values that drive rewards, coaching or insurer reports have real consequences. Clinically trained reviewers check uncertain readings, and their corrections should feed back so the system improves.
Yes. JondaX is a single API that turns lab reports, doctor's summaries, other clinical documents and photographed device readings into structured data configured to your own data model, with clinical review, ISO 27001 certification and in-country processing where required.
Jonda Health provides the health data layer for wellness platforms, so your team can focus on what members and clients experience.
About the author. Suhina Singh is Founder & CEO of Jonda Health. She has spent her career in healthcare, first as a doctor working in oncology, then in medical affairs and digital transformation roles across Asian markets, and as an investor in and builder of digital health products. She founded Jonda Health in 2022 to make health data usable for the people and systems that depend on it.
