The Hidden Engineering Tax of Using Document AI in Healthcare Products

When you are building a product that depends on clinical or lab data, document AI tools can feel like a breakthrough. You upload a PDF, the system extracts a table, test names appear, and numbers are captured. It can feel as though a major technical hurdle has just been cleared.

In reality, that is only the first step.

Extraction Is the Easy Part

We learned this firsthand while building a patient-facing application designed to help individuals manage and understand their own clinical data. Like many teams, we began by using document AI tools to extract information from lab and diagnostic reports.

The early results looked promising. Data appeared in structured form, and it seemed like we were close to being able to power meaningful features for patients. However, once we tried to use that extracted data in a real product, engineering reality set in.

We began encountering edge cases that were not obvious in early demos. Clinical units were sometimes partially captured or formatted inconsistently. Reference ranges varied in structure or contained subtle parsing errors. Abnormal result indicators, such as high and low flags, were missing or unreliable. The same test could be labeled differently across reports and laboratories. Small variations in terminology were enough to break downstream logic.

Individually, none of these issues seemed large. Together, they created a long tail of exceptions that quietly consumed engineering time.

The Long Tail of “Almost Structured” Data

What starts as “we just need to clean this up a bit” often turns into months of rule-building, normalization logic, and exception handling.

We found ourselves building systems to normalize units, validate reference ranges, recalculate abnormality indicators, and map varying test names to consistent concepts. We also had to account for lab-specific formatting quirks that repeatedly broke otherwise stable pipelines.

This work rarely appears in product demos, but it can dominate the roadmap. Instead of focusing on patient experience and core product value, engineering time becomes absorbed by making extracted data safe and consistent enough to use.

It Was Not Just Us

Later, we saw the same pattern repeat with a startup building a product that relied heavily on lab and diagnostic data. Their initial plan was to use document AI for extraction and then build their own normalization and harmonization layer on top.

After scoping the work required to handle real-world variability, the estimate for that data preparation layer alone was eight to ten months of engineering time or more.

Instead, they integrated with an existing harmonization layer that already addressed those inconsistencies, including units, reference ranges, abnormal flags, and terminology mapping. Their team was able to focus on their core product instead of building foundational data infrastructure.

What they expected to take most of a year was live in under a month.

Why This Matters for Builders

In healthcare and clinical AI, the hardest problems are often not in model performance or user interfaces, but in the reliability of the underlying data.

Extraction makes data visible. Productization requires that data to be consistent, comparable, and safe to use at scale.

For builders, the key question is not only whether data can be extracted, but how much engineering effort will be required before that data is truly usable inside a product.

Understanding that gap early can dramatically change timelines, team focus, and speed to market.

From Data Extraction to Data Foundations

This is the category of problem we ultimately focused on solving through Jonda Health and JondaX. After experiencing these challenges ourselves and seeing other teams face the same engineering burden, it became clear that the gap between extraction and usability was not a small technical detail, but a foundational layer that many healthcare products depend on.

Through Jonda X, we work on the stage that comes after document extraction, where clinical and diagnostic data must be standardized, validated, and aligned across both global medical standards and local system conventions. The goal is not simply to make reports readable, but to help product teams work with data that is consistent, interoperable, and ready to power real features at scale.

By addressing this layer, builders can spend less time creating custom normalization pipelines and more time focusing on the parts of the product that truly differentiate their offering.

‍