I’m Fillip Kosorukov. I’m not a doctor, and nothing here is medical advice. This is about a boring data problem I ran into after building an app to pull years of my own bloodwork into one place.
The app could store the numbers. The real question was which rows belonged on the same trend line. One bad merge can make a stable marker look like it jumped.
The trend that did not match the reports
For a lab tracker, the useful part is keeping repeat values attached to the right marker over time. A single cholesterol number or vitamin level is just one report.
When I first lined everything up, a few trends looked wrong. One marker seemed to drop and rebound even though the original reports were stable. Another showed up twice in the same month. A couple of measurements I knew I had taken were missing from the chart.
The source reports checked out. The bad step was in the import logic that decided, “this March result and this June result are the same thing.”
The LOINC trap
LOINC exists to make lab tests comparable across providers, and I still store it. The mistake was treating the code as the whole identity of the marker.
The same underlying measurement can arrive under different LOINC codes depending on the lab, method, or panel context. LDL is a good example: LOINC 2089-1 is LDL cholesterol in serum or plasma with no method specified, while 18262-6 is LDL cholesterol by direct assay. Both can look like “LDL” in a friendly app label, but I keep the method difference in the mapping rule before comparing values.
A few old imports had incomplete or ambiguous code data, so loose name matching created the opposite risk: it could guess too aggressively and merge rows that needed review. Those rows now get marked for review, with the original report attached for the manual check.
The rebuild
I rebuilt the importer so the unit of identity is marker plus method. “LDL cholesterol” is not enough by itself; a direct assay and a method-unspecified LDL row may need different handling. The mapping table now stores the canonical marker, method bucket, and source row together.
In that mapping, an LDL row with LOINC 2089-1 lands in an LDL / method-unspecified bucket, while 18262-6 lands in LDL / direct-assay. Both can still display in an LDL context, but they are not collapsed into the same source identity.
I still use the LOINC field, but only as one clue alongside the rest of the row. Every plotted point also keeps a link back to the original report, so I can check the source row when something looks odd.
After that rebuild, the chart got quieter. Some duplicate-looking months pointed back to the same source result and got merged. Rows that had been stranded under old labels moved into the marker I expected.
The charts now matched the source reports. The remaining outliers were real rows to review, not artifacts from the import.
What I would check in any health app
My first test for any lab app now is simple: click a charted point and make sure it opens the source report behind that value. I also want direct and method-unspecified results labeled separately, and unmatched rows shown for review instead of silently guessed into a trend.
About the author
Fillip Kosorukov co-authored peer-reviewed behavioral-psychology research on protective behavioral strategies and motivational interviewing (Journal of Substance Use, 2023; PMID: 37275205) and holds a BS in Psychology (Summa Cum Laude) from the University of New Mexico. He writes about applied decision-making, measurement, and the systems people use to understand their own behavior and health. This article is about data integrity, not medical advice.
Elsewhere:
ORCID ·
Google Scholar ·
LinkedIn ·
fillipkosorukov.net ·
fillipkosorukov.me
