Every digital health platform built in Brazil over the last five years has gone through the same product decision: what to do when the user tries to insert their laboratory test results. Most of these platforms landed at the same answer: accept the lab report PDF, store the file, and display the document when the user asks for it. Some add the lab report photo captured by camera. Others integrate with Google Drive or WhatsApp. The functional result is the same: the PDF entered the system and stayed there, intact.
This decision is presented as user convenience. It is, technically, abandonment of the data layer.
PDF is not data: it is image of data
The distinction looks subtle but has structural consequences for any digital health platform. A laboratory report PDF is, in most cases, a document that visually reproduces the results produced by the Laboratory Information System. It contains the numbers, the units, the reference ranges, and the test identification. What it does not contain, in software-accessible form, is the semantic structure that makes those elements treatable as data.
For any algorithm, any longitudinal comparison, any integration with other data sources, the PDF must be converted. Conversion involves OCR to extract text, parsing to identify which fragments are numerical values, mapping to recognize which analyte is being measured, unit normalization, reference range identification, consistency validation. Each step introduces opportunities for error. The Institute of Medicine, in a central publication on health IT and patient safety, observes that the quality of clinical data is the foundation on which any health automation is built, and that unstructured data compromises that foundation.
Platforms that stop at the PDF deliver to the user a digitized version of the same problem they had on paper: documents that are readable, but not actionable, not comparable, not integrable.
What this means in user experience
User experience on a platform that stores PDFs without extracting their data is easily recognizable to anyone who has tried to use one. The user uploads the report. The platform confirms the upload. When the user comes back weeks later to check the evolution of some biomarker, they discover they need to open each PDF individually, locate the result inside the document, and mentally perform the comparison the platform should be performing for them.
This friction is why most of these platforms lose the user after the second or third upload. Not because the user stopped caring about their health. Because the platform isn't offering anything they couldn't get doing the same in Google Drive: file storage. Without automated comparison between tests from different periods, without trend-based alerts, without integration with other points of the health journey, the platform's added value converges to the added value of a well-organized PDF folder.
Research on health technology adoption consistently shows that the depth of data structuring is strongly correlated with user retention. When the platform transforms PDFs into comparable time series, with recognized biomarkers, mapped reference ranges, and automatic comparison across periods, the user starts using it for something they couldn't do with simple file storage. When it stops at the PDF, it competes with Google Drive, and Google Drive is free.
The technical cost of deferred structuring
The decision to accept PDFs without structuring them is frequently justified as technical complexity savings in the MVP. The logic is direct: structuring laboratory data is hard, let's first validate the product with something simple, then we invest in the data layer. This logic fails for two reasons.
The first reason is that the product being validated with unstructured PDFs is a different product from the product the team wants to build. The validation isn't being done on the real value proposition, it's being done on a simplified version that can't adequately differentiate between users satisfied with file storage (a segment easily served by Google Drive) and users who would value data structuring (the segment that justifies product investment). Retention and engagement numbers measured over the unstructured product systematically underestimate the real potential of the structured product.
The second reason is that the deferred structuring work doesn't just stay deferred. It accumulates. Every PDF accepted without structuring is one more item that will need retrospective processing when the platform decides it needs the data in structured form. Platforms that ran two or three years accepting PDFs without extracting data frequently discover, at the moment of structuring decision, that the retrospective processing backlog is bigger than the team can address without compromising future roadmap. The original choice that looked like savings converts into technical debt that grew for years.
The literature on health interoperability identifies recognized standards like LOINC for universal identification of laboratory tests. These standards exist precisely to solve the problem of comparability between data produced by different systems. Platforms that store PDFs without mapping their content to those standards are, in practice, choosing not to use the interoperability infrastructure the global health ecosystem has built over decades.
The difference between convenience and structure
There is an important distinction between making PDF upload convenient for the user (something every platform should do) and treating the PDF as the data's final destination (something that compresses the value the platform can deliver). The two decisions look close but lead to completely different products.
The platform that treats the PDF as a convenient entry point but extracts and structures its data immediately after upload offers the user the best of both experiences: they upload a simple document, and the platform delivers a structured representation that accumulates, over time, into a usable clinical history. The platform that treats the PDF as final destination offers the user a document repository. The difference isn't in the initial interface. It's in everything that happens afterward.
Vest and Gamm, in one of the main reviews on health interoperability, observe that fragmentation of clinical data is one of the largest sources of operational inefficiency in health organizations, and that technical integration without semantic structuring resolves only the simplest part of the problem.³ The observation applies directly to digital health product design: integrating with data sources is half the work. Structuring what was integrated is the other half, and it's the half that differentiates products that retain users from those that just accumulate uploads.
The data layer as a product decision
For early-stage healthtechs, the decision on how to treat laboratory data is a product decision, not an isolated technical decision. It defines what the platform is capable of doing, defines which user segment it can retain, defines which value proposition it can communicate honestly.
Building this layer internally requires engineering investment that rarely pays back at an early-stage healthtech. PDF parsing, LOINC mapping, unit normalization, consistency validation, coverage across hundreds of format variations between Brazilian laboratories, ongoing maintenance as report layouts change. The time the team spends on this work is time not spent on the platform's differentiated value proposition. And the result, even when well-executed, is an infrastructure layer every competitor of the healthtech is building in parallel, with the same probability of success.
Structuring laboratory data is the kind of problem that makes more sense to treat as purchased infrastructure than as in-house engineering. Not because it's impossible to solve internally, but because solving internally consumes runway without generating competitive differentiation.
This is where OpenHealth Technologies operates. The platform automatically correlates multiple data streams with rigorously validated logical layers of laboratory tests, receiving laboratory report PDFs in any format and delivering structured data, mapped to LOINC, with over 3,500 biomarkers covered. For healthtechs, this means the time that would be spent building the extraction and harmonization layer is now spent on the value proposition that actually differentiates the product: clinical experience, monitoring model, integration with the user's health journey. The PDF stops being the final destination of the data and goes back to being just a convenient entry point, with the real work happening in the layer the user doesn't see, but whose result they perceive immediately.
Learn how your platform can transform PDF uploads into structured, comparable time series, without investing internal engineering in problems that don't differentiate the product.