A lab result is a number plus the conditions it was produced under. Lose the conditions and a correct value can still lead to the wrong conclusion. Here is what to keep, and why.
In our first guide in this series, we looked at ten lessons engineers tend to learn after their first health data integration goes live. One of them was that a number without its unit is not a result. This guide takes that idea further, because the unit is only one of several pieces of context that decide what a value actually means.
Clinicians interpret results with this context in mind, often without thinking about it. Software does not have that instinct. If your data model keeps only the test name and the number, your charts, alerts, AI features and reports are working with less information than the person who ordered the test. Each section below explains one type of context, shows why it matters, and ends with a check for your own design.
Many common tests are reported in International System of Units (SI units) in much of Asia, Europe and Australia, and in conventional units in the United States and some other markets. The difference is not cosmetic. The same result can differ by a factor of 18, 38 or 88 depending on the unit, so a value that looks normal in one system looks alarming, or meaningless, in the other.
Notice that the conversion factor is different for every test, because it depends on the molecular weight of what is being measured. A single "convert mmol/L to mg/dL" function does not exist. Conversions need to be defined per analyte, tested, and applied only when the source unit is known with certainty.
Check: if a result arrives with a missing or unrecognised unit, does your system stop and flag it, or does it guess?
The same analyte measured in different specimens gives different numbers. Glucose measured in plasma is around 11% higher than glucose measured in whole blood from the same sample, which is why the International Federation of Clinical Chemistry and Laboratory Medicine (IFCC) recommends reporting glucose as a plasma-equivalent value2. A finger-prick reading from a home glucose meter and a venous sample processed in a laboratory are also different measurements, and many products receive both.
Protein, creatinine and glucose can also be measured in urine, where the reference ranges and units are completely different from blood. If your model stores only "glucose: 5.8", you cannot tell which of these it was.
Drawing these on one unlabelled line suggests changes that may simply come from the type of sample.
Check: does every result in your system record its specimen type and, where relevant, whether it came from a lab or a home device?
Some results only make sense alongside when the sample was taken. Fasting and random glucose are interpreted against different thresholds. Cortisol follows a daily rhythm and peaks in the early morning, which is why a morning sample is used when adrenal insufficiency is suspected3. Triglycerides rise after a meal, and while non-fasting lipid profiles are now widely accepted for routine testing, the fasting status still affects how a borderline result should be read4. For medicines that are monitored in the blood, the time since the last dose determines what the level means.
This information is often printed on the report as a small annotation, or embedded in the test name itself, such as "Glucose (F)" or "Cortisol 8am". If it is not captured as a structured field, it disappears the moment the value is extracted.
Check: when a lab marks a sample as fasting or timed, where does that information end up in your data model?
Laboratories measure the same analyte using different methods, reagents and instruments, and the results are not always interchangeable. Cardiac troponin is a clear example: high-sensitivity assays and older conventional assays report on different scales, and each assay has its own decision threshold based on the 99th percentile of a healthy reference population, which can also differ by sex5. Vitamin D, hormones and some tumour markers show similar variation between methods.
This is the underlying reason reference ranges follow the laboratory rather than the test. When a patient's results come from two labs that use different methods, a change in the number may reflect a change in method rather than a change in the patient.
Check: if a patient switches labs, can your product tell users that a change in trend might come from a different method?
Several results that look like measurements are actually calculated from other results. Estimated glomerular filtration rate (eGFR), a key measure of kidney function, is calculated from creatinine, age and sex using an equation, and different equations give different answers. The 2021 CKD-EPI equation6 is recommended in the current KDIGO (Kidney Disease: Improving Global Outcomes) guideline7, but older reports and some labs still use the earlier MDRD (Modification of Diet in Renal Disease) study equation8.
The same creatinine result lands either side of 60 depending on the equation, a threshold used in staging chronic kidney disease.
Low-density lipoprotein (LDL) cholesterol is similar. It can be measured directly or calculated using the Friedewald equation9 or newer approaches such as the Martin-Hopkins10 and Sampson11 equations, which perform differently when triglycerides are high or LDL is low. Labs also change equations over time, so a patient's own trend can shift for reasons that have nothing to do with their health.
Keeping a calculated value traceable
{
"test": "eGFR",
"value": 64,
"unit": "mL/min/1.73m2",
"calculated": true,
"equation": "CKD-EPI 2021",
"inputs": { "creatinine": { "value": 88, "unit": "umol/L" } }
}
Check: if your product recalculates eGFR or LDL itself, does it say which equation it used, and does it avoid mixing its own values with the lab's on one chart?
What counts as expected depends on who the patient is. Alkaline phosphatase is normally much higher in children and adolescents because of bone growth, so an adult range would flag a healthy teenager. Haemoglobin thresholds for anaemia are lower in pregnancy: the World Health Organization uses 110 g/L in the first and third trimesters and 105 g/L in the second, compared with 120 g/L for non-pregnant women12. Even here, units matter, because some labs report haemoglobin in g/dL instead.
Your system does not need to become a clinical decision tool to handle this well. It needs to keep the age, sex and pregnancy status that applied at the time of the test, and avoid applying a single generic range to every patient.
Check: if your app shows a "normal range", whose range is it, and does it change for a child or a pregnant user?
Some errors happen before any clinical interpretation, at the level of the characters on the page. Much of Europe and Latin America uses a decimal comma, so "5,4" means five point four, and a parser expecting a decimal point may read it as 54 or reject it. Thousands separators, rounding to different precisions and results split across table cells can all distort a value during extraction.
Laboratories also attach comments that change whether a value should be used at all. A potassium result from a haemolysed sample can be falsely high, because damaged red cells release potassium into the sample. Comments such as "haemolysed", "lipaemic", "clotted", "insufficient sample" or "result to follow" need to travel with the value, not be dropped as free text.
A value that should not be trusted on its own
{
"test": "Potassium",
"value": 6.1,
"unit": "mmol/L",
"sample_quality": "haemolysed",
"lab_comment": "Please repeat. Result may be falsely elevated."
}
Check: test your parser with "5,4", "1.234,5" and a result with a haemolysis comment. What does it store?
A useful rule of thumb is that every result should carry enough context for a clinician to interpret it without seeing the original report: the unit, the specimen, the timing, the method or equation, the patient context and any quality comments. That sounds like a lot of fields, but most of them already exist in FHIR (Fast Healthcare Interoperability Resources) and in well-structured lab messages. The challenge is capturing them reliably from sources that do not provide them neatly, which is where most of the effort in a health data integration goes.
Examples and calculations are illustrative and simplified. They are not clinical guidance.
