Turning clinical lab reports into structured data

Clinical lab reports are high-value and stubbornly hard documents in health tech. They arrive as faxes, scanned PDFs, and printouts from thousands of labs, with layouts that vary from lab to lab — yet the data they carry (results, units, reference ranges, abnormal flags) has to land cleanly in an EHR, a care-operations queue, or a clinical AI pipeline. This cookbook walks through what a lab report actually contains, why naive extraction breaks on them, the schema to target, and how to build a reliable pipeline with Reducto.

What a lab report contains

In the United States, the content of a lab report is governed by CLIA — specifically 42 CFR 493.1291, the test-report standard. The regulation dictates what information must be conveyed, not how it must look. A report must include the patient's identification, the name and address of the laboratory performing the test, the date of the report, the test performed, and the specimen information. Each result must be reported with its units of measurement or interpretation, or both, where applicable — qualitative results may carry neither. Pertinent reference intervals must be available to the ordering clinician. Critically, no specific visual format is mandated — which is exactly why no two labs' reports need to look alike.

Underneath that regulatory envelope, the structure is consistent in shape if not in layout:

• Panels — grouped orders such as a Complete Blood Count (CBC) or a Comprehensive Metabolic Panel (CMP).

• Analytes — the individual measurements inside a panel (e.g., hemoglobin, glucose, creatinine).

• Result, units, reference range, and flag for each analyte, where flags follow conventions like H (high), L (low), or critical markers.

Test names in these reports are local to the lab. Downstream systems standardize them using LOINC — universal codes for laboratory tests and observations, maintained by the Regenstrief Institute and free to use. For electronic transmission of lab results, CMS recommended HL7 version 2.5.1 with LOINC (CMS S&C-10-12) — longstanding guidance that CMS has since marked expired (December 2025), though the HL7 v2.5.1 + LOINC pairing it recommended remains the basis of electronic lab reporting practice — and FHIR resources (Observation, DiagnosticReport) carry LOINC-coded results further downstream. LOINC mapping is a job for your system — extraction's job is to hand it clean, verbatim source data.

Why lab reports are hard to parse

Three properties make lab reports resistant to naive extraction:

Units and reference ranges are lab- and method-specific. The same analyte can carry different reference intervals at two different labs depending on the assay, the instrument, and the reference population. A creatinine "normal range" from one lab is not interchangeable with another's. Never normalize away the printed range. The reference interval that appeared on the report is the one the ordering clinician was meant to see, and it is what makes a result interpretable. Strip it or substitute a "standard" range and you have silently changed the clinical meaning of the result.

Local test names need mapping downstream. A report may say "GLUC," "Glucose, Serum," or "Glucose Lvl" for the same measurement. Reconciling these to a canonical code is LOINC's role, performed in your pipeline — but only if extraction preserved the exact printed name.

Layouts fight row-based extraction. Cumulative reports lay results out in columns, one per encounter or draw date, so a single analyte spans a row of historical values. Panels nest analytes under headers, and sub-results (like a differential inside a CBC) nest further still. Faxed originals add skew, noise, and low resolution on top. A naive row-by-row scrape flattens these structures, misaligns columns, or drops the panel grouping entirely.

These properties defeat traditional extraction by design. Row-based rule extraction assumes one analyte per row with fixed columns, so a cumulative report — encounters printed as columns, analytes nested under panels — misaligns results against the wrong ranges or dates when scraped row by row; per-lab templates don't rescue it, because layouts vary lab to lab and the template library grows without bound; and flat OCR text dumps often drop the H and L flag characters or detach them from the analyte they qualify. What the job requires is parsing that preserves the panel-analyte hierarchy and the column relationships as structure, not as undifferentiated text.

What to extract

Target a nested schema that mirrors the document rather than a flat table:

• Document metadata — patient identifiers, ordering provider, performing laboratory name and address, report date, specimen information (type, collection date, accession).

• Panels[] — each with its panel name and the analytes it contains.

• Analytes[] — for each: name (verbatim, as printed), result, units, reference_range (as printed), and flag.

Two rules make this schema trustworthy for clinical use:

• Keep the printed reference range alongside any normalized value. If your system computes a standardized value, store it in addition to, never instead of, the range the lab printed.

• Attach a citation to every analyte. A bounding-box citation back to the exact location on the source page lets a reviewer verify each extracted result against the original — essential when the downstream consumer is a clinician or an audited workflow.

Building it with Reducto

The pipeline is two stages plus citations. No custom orchestration required — configure each step and chain them.

1. Parse the document. Start with Parse to turn the report into structured, machine-readable content, preserving columnar and multi-encounter layouts. For faxed and scanned originals, tune the OCR settings so low-resolution and skewed inputs are read reliably before any structured extraction runs. This is the flow Reducto's healthcare document parsing cookbook demonstrates on messy healthcare inputs — lab reports among them — parsed into clean, structured text in a single operation.

2. Extract into the nested schema. Use Extract with Deep Extract over the nested schema so panels and analytes come back as nested arrays rather than a flattened grid — this is what keeps analytes bound to their parent panel and preserves each printed reference range. Deep Extract runs at production scale — 120M+ fields extracted on documents up to 11k pages, with 99–100% field accuracy in Reducto's July 2026 head-to-head against frontier models and human annotators.

3. Turn on citations. Enable citations so every extracted field links back to its location on the source document, giving you per-analyte provenance for clinical review.

LOINC mapping happens after this, inside your system. Reducto supplies the verbatim test names, results, units, and ranges that your mapping layer needs. For the broader picture of Reducto in clinical settings, see reducto.ai/industries/healthcare.

Validating accuracy

Because these results feed clinical decisions, build validation into the pipeline:

• Flag-vs-range consistency. A result that falls outside its printed reference range should carry an abnormal flag; a result inside the range should not. Mismatches surface either an extraction error or an unusual source report worth review.

• Unit-presence audits. CLIA requires units or interpretation on every result where applicable (qualitative results may carry neither). Audit for any analyte extracted without units — a missing unit is a red flag for a misread row.

• Per-analyte citation spot-checks. Sample extracted analytes and confirm each citation points at the correct value on the source page.

Compliance and deployment

Reducto supports HIPAA with a signed Business Associate Agreement (BAA) on the Growth and Enterprise tiers, and Zero Data Retention (ephemeral processing) on Growth and Enterprise. VPC and on-premise deployments are available exclusively to Enterprise customers, alongside the default SaaS option. Details are on the Enterprise readiness page.

FAQ

Can Reducto handle cumulative reports with a column per encounter?

Yes. Parse preserves columnar and multi-encounter layouts, and a Deep Extract schema lets you capture each analyte's series of dated results rather than collapsing them into a single value.

Does Reducto assign LOINC codes?

No. Reducto does not assign LOINC codes. It extracts the verbatim test names, results, units, and reference ranges from the report — the exact source data your downstream LOINC-mapping layer needs to standardize the results.

Does it work on faxed and scanned lab reports?

Yes. Configure the OCR settings in Parse for faxed and scanned originals so low-resolution, skewed inputs are read reliably before extraction.

Will it normalize reference ranges to a standard set?

No — and it should not. Reference ranges are lab- and method-specific. Reducto extracts the range exactly as printed; keep that printed range with any value your own system normalizes.

Is it HIPAA compliant?

Reducto offers HIPAA with a signed BAA on the Growth and Enterprise tiers. See the Enterprise readiness page for the full compliance and deployment matrix.