Laboratory results are among the most valuable real-world data, and among the hardest to combine across sites, countries and languages. This guide sets out 12 things to check before you analyse.
If you work in medical affairs, real-world evidence, health economics or digital innovation, you already know how much real-world data could do: show how a therapy performs outside a trial, describe a patient population nobody has characterised, support an access submission, or make a patient support programme more responsive. You probably also know how often the ambition meets two practical barriers.
The first is access. The data you want exists, but it sits with hospitals, laboratories and clinics that have no straightforward way to share it. The second is usability. The data you do manage to obtain arrives as a mixture of spreadsheets, system exports, PDFs and scans, from different sites, in different languages, with every laboratory naming and measuring things in its own way. Our founder spent years on the pharmaceutical side of healthcare, and these were the two barriers her teams met most often. They were never short of interest in using health data. What they lacked was data in a form they could use.
Laboratory results deserve particular attention, because they are objective, repeated over time and central to most disease areas, and because they are unusually difficult to combine. This guide sets out twelve things to check before you begin analysis. It follows the two questions that regulators and reviewers generally ask of real-world data, whether it is relevant and whether it is reliable, and adds two more that decide whether a project succeeds in practice: whether you are permitted to use the data, and whether your work can be reproduced.
In most real-world data projects, the steps before analysis take the larger share of the time and budget. Understanding them early is the best way to set a timeline you can keep.
It is tempting to collect everything available and decide later what to do with it. That approach makes every subsequent step slower and more expensive, and it complicates the privacy position. Begin with the research question and work backwards: which laboratory tests matter, in which population, over what period, alongside which other information such as diagnoses, treatments and outcomes. Write this down as a minimum dataset. It gives data partners something concrete to respond to, and it gives your privacy and ethics reviewers a clear purpose to assess.
Real-world data reflects who was tested, where and why. A dataset drawn from private hospitals in capital cities describes a different population from one drawn from public clinics in the provinces. Patients who are tested frequently are often those who are sicker or better insured. Check which sites, regions and patient groups your data covers, and whether that matches the population your question concerns. This matters especially in Asia, Africa and the Middle East, where populations are under-represented in most published evidence and where well prepared local data is correspondingly valuable.
A single laboratory value rarely answers a research question. Most questions depend on the trend in a marker over months or years, measured against the start of a treatment or the occurrence of an event. Check how far back the data goes for each patient, how frequent the measurements are, and whether results can be linked to the same patient across visits, across sites and across data types. Where patients move between providers, ask how identity is resolved, because a patient counted twice or a history divided in two will distort your findings without any visible sign.
For any number in your analysis, you should be able to say where it came from: which site, which laboratory, which source document or system, and what was done to it on the way to your dataset. Provenance is what allows you to answer a reviewer's question, investigate an unexpected result and defend your findings under audit. Ask your data partners whether each value can be traced back to its source, and whether the original is retained.
This is the central challenge of laboratory data. Across sites and countries, one test appears under many names, abbreviations and languages, and must be resolved to a single concept. The opposite problem also occurs, where results that look alike are not comparable. A glucose measured in urine is a different test from one measured in blood. Troponin results from different assays cannot simply be pooled. HbA1c may be reported as a percentage or in mmol/mol. Mapping to medical coding standards, with attention to specimen and method, is what makes pooling legitimate. Ask how the mapping was done, who reviewed it, and how ambiguous cases were handled.
Different laboratories report the same analyte in different units, and conversion factors are specific to each analyte. Converting glucose from mg/dL to mmol/L uses a different factor from cholesterol or creatinine. An error here produces values that are wrong by a constant multiple, which can be surprisingly hard to notice in aggregate. Check that conversions were applied per analyte, that the original value and unit were kept, and that the distribution of each converted variable looks sensible for every site.
Reference ranges differ between laboratories because methods and populations differ. If your analysis uses "abnormal" as a variable, it matters whether that was judged against the reporting laboratory's own range or against a single range applied across the whole dataset. Both approaches can be justified, provided the choice is deliberate and documented. Check that the original range and flag were captured with each result, so that the choice remains yours to make.
In many markets a large proportion of laboratory data exists only as PDFs, scans and paper, in local languages. Including it can greatly improve coverage, and it introduces a step that needs its own quality measurement. Ask how extraction accuracy was measured, on what sample, at the level of individual fields, and what clinical review was applied. Ask how decimal points, comparators such as "<0.5" and translated test names were verified. An extraction error rate that is known and documented can be managed, and one that is unknown cannot.
Real-world laboratory data contains results below the detection limit, the same result received from two sources, values that are physiologically impossible, and gaps where a test was never ordered. Each of these calls for a rule, such as how results below the limit are represented, how duplicates are identified and how implausible values are flagged. Agree the rules before you look at the outcomes, apply them consistently, and record them, so that they cannot be mistaken for choices made to improve the result.
Permission has to be established for each source and each country, because the rules differ. Confirm the basis on which the data was collected and whether it extends to research or commercial use, whether ethics approval is required and from whom, and whether the data may leave the country in which it was collected. Several countries in Asia have introduced or strengthened personal data protection laws in recent years, and some expect health data to be processed locally.
De-identification deserves particular care with laboratory data. Removing names and identity numbers is only the beginning. Identifiers hide inside scanned documents and free-text comments, and a combination of exact dates, a rare result and a small clinic can point to one individual even when no name is present. Ask how identifiers within documents were found and removed, how dates were treated, and how the risk of re-identification was assessed. Involve your privacy and legal colleagues at the design stage. It is far easier to build permission into a project than to establish it afterwards.
Evidence that is going to be submitted, published or relied upon for a decision has to be reproducible. That requires a data dictionary describing every variable, a record of each transformation that was applied, versioned terminology mappings and the ability to run the whole preparation again and arrive at the same dataset. Ask any data partner what documentation they provide with the data. A dataset that arrives with none leaves you unable to answer the questions a reviewer is most likely to ask.
A retrospective study needs a dataset prepared once and frozen. A patient support programme, a registry or an ongoing safety commitment needs data that continues to arrive, prepared in the same way each time. The second is a pipeline, and it is worth designing as one from the beginning. Much of the effort in a first project goes into work that can be reused, including mappings, rules and agreements. Teams that plan for reuse find that their second and third projects cost a fraction of the first. Teams that treat each project as a separate exercise pay the full cost every time, and this is often the shortcut that makes a promising first use case hard to repeat.
Jonda Health works with pharmaceutical, research and digital health teams on both of the barriers described at the start of this guide.
On usability, JondaX is our health data transformation engine, and for research teams it serves as a real-world data harmonisation engine for laboratory data. It takes laboratory results in the forms they really arrive in, including system exports, HL7 and FHIR files, CSV, PDFs, scans and images, in more than ten languages, and produces consistent, analysis-ready data. JondaX uses AI to extract results from documents, resolve the different ways the same test is captured across sites and countries, normalise units, and map results to medical coding standards, with clinical review and quality assurance carried out by Jonda Health's own team. Documents are de-identified as part of processing. The same pipeline can be run once for a retrospective study or continuously for a programme or registry. To date JondaX has processed more than 500,000 files and more than 26 million data points.
On getting from question to execution, Jonda Health Services supports teams that would like a partner earlier in the process: shaping a use case that will show value, assessing whether the data available can support it, working through sourcing and permissions, and carrying a project from plan to delivery. Our team has worked in clinical practice, in medical affairs and digital innovation within the pharmaceutical industry, and in health data and AI, so we understand the pressures on both sides of the conversation. Nobody can be an expert in all of it, and you do not need to have everything worked out before getting in touch.
Jonda Health is ISO 27001 certified, and JondaX is designed to comply with HIPAA, GDPR and PDPA.
If you have a real-world data question in mind, or a dataset that is proving harder to use than expected, we would be glad to talk it through. Get in touch at hello@jonda.health.
It is the process of bringing data from different sources into one consistent form, so that the same test, unit and concept are represented in the same way regardless of where the data came from. It is what makes it legitimate to pool and compare data across sites and countries.
Every laboratory names, codes and measures tests in its own way, results often exist only as PDFs or scans, reference ranges differ between laboratories, and in many regions reports come in several languages. Each of these has to be resolved before results can be combined.
Reviewers generally look at two things: relevance, meaning that the data covers the right population, variables and time period for the question, and reliability, meaning that the data is accurate, complete, traceable to its source and prepared in a documented and reproducible way.
Yes, provided the extraction is accurate and that accuracy has been measured. Including documents can greatly improve coverage, particularly in markets where much of the data has never been held in structured systems. Ask for field-level accuracy figures and details of the clinical review applied.
No. Identifiers also appear inside documents and free text, and a combination of exact dates, rare results and small sites can point to an individual. De-identification should cover the content of documents and include an assessment of re-identification risk.
Jonda Health. JondaX, its health data transformation engine, harmonises laboratory data from system exports, PDFs and scans across more than ten languages into analysis-ready data, and Jonda Health Services supports pharmaceutical and research teams from use case design through sourcing to delivery.
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.
