Your EHR Is Digital. So Why Do Lab Results
Still Travel by Screenshot?

The Screenshot Pipeline Nobody Planned For

It begins with a fax. A PDF attachment in an email from the hospital's medical records department. A portal login for a reference lab the practice doesn't have an HL7 interface with. The end result is the same: a clinical staff member is looking at lab values on a screen they can't export from, so they take a screenshot. Or they print to PDF and save it to the patient's chart as an attachment — searchable by nothing, structured for no one.

This workflow is not an edge case. A 2025 scoping review of EHR usability challenges documented that resident physicians assembling a single patient snapshot during pre-rounding navigated 28 separate EHR screens in an average of 6 minutes and 27 seconds — largely because labs, medications, and notes could not be viewed together on a single screen. The fragmentation isn't a design flaw in any one system. It's the predictable result of an ecosystem where data standards exist on paper but break in practice.

When an outside lab result arrives at a practice running Epic, it can take one of three paths. Path one: the lab has a working HL7 interface with that specific Epic instance — the result flows into structured fields automatically. Path two: the result arrives as a PDF or fax, and someone types every value into the EHR by hand. Path three — increasingly common as practices consolidate and patients move between health systems — is the screenshot: faster than typing, shareable in a message, but leaving the data trapped in an image that no EHR can query, trend, or include in clinical decision support.

A systematic review published in 2021 found that physicians spend 37% of their workday interacting with the EHR — and that's just time logged within the system, not counting the screenshots, portal logins, and workarounds that happen outside it. The screenshots are invisible to the EHR's event log. They don't show up in any productivity dashboard. But they're there — and someone is re-typing them.

Why “Just Integrate It” Hasn't Happened in Two Decades

Healthcare has interoperability standards. HL7 v2 has been parsing lab messages since the 1990s. LOINC (Logical Observation Identifiers Names and Codes) provides universal codes for laboratory observations — every sodium result, every hemoglobin value, every TSH level has a standardized identifier. FHIR (Fast Healthcare Interoperability Resources) is the modern standard designed to make data exchange as simple as a REST API call.

So why do screenshots still exist?

The first answer is mapping. A 2026 study in JMIR Medical Informatics found that 6% to 19% of laboratory tests cannot be accurately mapped to LOINC codes, even with automated systems designed specifically for the task. Each reference lab uses its own internal test codes. Each EHR uses its own data dictionary. The mapping between them — the "crosswalk" — requires manual curation and regular maintenance. When a lab adds a new test or changes a reference range, the crosswalk breaks. The interface stops ingesting results. The workflow falls back to manual.

The second answer is economics. Building and maintaining a single HL7 lab interface costs between $5,000 and $30,000, depending on the complexity of the mapping and the vendor's professional services fees. A small practice that receives results from Quest, LabCorp, a local hospital lab, and a specialty reference lab would need four interfaces — an up-front investment of $40,000 to $120,000 before accounting for annual maintenance. For a 2-physician practice, that's a capital expense that's hard to justify against just having the medical assistant type the values in.

The third answer is organizational. Roughly 80% of healthcare data is unstructured and resides in disconnected systems according to industry research. The HITECH Act of 2009 successfully incentivized EHR adoption — it did not mandate interoperability between the systems it subsidized. Two decades later, a hospital running Epic and a specialist running eClinicalWorks might as well be on different planets. The screenshot isn't a failure of technology. It's the lowest-common-denominator format that reliably survives the crossing.

What Manual Lab Entry Actually Costs Per Report

A routine lab panel — CBC with differential plus comprehensive metabolic panel — contains roughly 25 discrete data points. The medical assistant doesn't just type the numbers. They navigate to the patient's chart, open the lab entry module, locate each test name (often from a dropdown without type-ahead), enter the value, select the correct unit, type or verify the reference range, and flag abnormals. CMS's SAFER guide for test results reporting specifies that paper-based results must be entered with at minimum these discrete coded fields: Test Result Name, Test Result Value, Units, Normal Range, Abnormal Flag, and Date/Time.

Ten minutes per report. At a loaded medical assistant wage of roughly $28 per hour, that's $4.67 per lab panel in pure labor cost. A small 2-physician primary care practice receiving 80 to 120 non-integrated lab reports per month spends $370 to $560 monthly — $4,400 to $6,700 annually — on a task that generates zero revenue and adds zero clinical value.

But the labor cost is the cheap part.

Transcription errors are the expensive part. A 2019 study of point-of-care glucose testing found a manual transcription error rate of 2.8% when lab values were re-entered into the EHR (PMC6351970). In the ICU setting, Black et al. found an 8.8% transcription error rate in laboratory results (2013). Each error triggers one of two outcomes, both bad: the provider acts on incorrect data, or someone catches the error and re-enters the value — doubling the labor cost of that single data point.

For specialty practices, the math compounds. A nephrology practice managing 200 dialysis patients — each requiring monthly labs for serum creatinine, BUN, eGFR, electrolytes, phosphorus, PTH, hemoglobin, and iron studies — receives roughly 200 lab reports per month. If half arrive as unstructured documents from outside facilities, that's 500 or more individual data entry tasks per month before accounting for non-dialysis CKD patients and transplant follow-ups. The numbers stop being a rounding error and become a staffing decision.

How AI Reads a Lab Screenshot Differently Than OCR

Traditional OCR (Optical Character Recognition) works on position. It scans an image for pixel patterns that look like characters, converts them to text, and outputs whatever it finds. If the lab report says "Sodium | 138 | 135-145 | mmol/L," OCR returns the string "Sodium | 138 | 135-145 | mmol/L" — a flat block of text with no understanding that 138 is the value, 135-145 is the reference range, and mmol/L is the unit. Getting structured data out of that flat text requires post-processing: regular expressions, rule-based parsers, template matching. And templates break the moment the lab changes its report layout — which they do. Frequently.

AI semantic extraction works on meaning. Instead of searching for text in a fixed position, the model reads the document the way a human does — it identifies sections ("Chemistry Panel," "Hematology"), understands that values under "Result" belong to tests listed under "Test Name," and recognizes that an asterisk or an "H" next to a number means "abnormal, high." This is the core distinction between position-based extraction and semantic-based extraction: one cares where data sits; the other cares what data means.

The practical consequence is format independence. A CBC report from Quest uses one layout. The same panel from LabCorp uses a different layout. A screenshot from a hospital portal uses a third. OCR-based systems need a separate parsing template for each one — and maintenance when any of them change. Semantic AI reads all three the same way: by understanding that hemoglobin is hemoglobin, regardless of which column it appears in, which font it's printed in, or whether the report header says "Quest Diagnostics" or "ARUP Laboratories."

This approach also handles the edge cases that break template systems. Handwritten annotations from a pathologist. Reference ranges printed in a smaller font below each value. Results split across two pages in a PDF. These are everyday occurrences in clinical lab workflows — and each one is a point of failure for position-based extraction that semantic AI absorbs without custom configuration.

A Practical Workflow: Screenshot to Spreadsheet in Under a Minute

Here is the workflow, step by step, replacing the manual re-entry loop that currently consumes a medical assistant's morning:

For practices managing patients across multiple reference labs, the batch workflow eliminates the most tedious part of the process: the "merge step." Instead of extracting results from Quest into one spreadsheet, LabCorp into another, and then manually aligning rows by patient name or MRN, a single batch upload processes everything together. The AI matches patient identifiers across reports — same name across different lab formats becomes one row with all values populated.

This workflow doesn't replace an HL7 interface. If you have the budget and the IT support to build interfaces to every lab your practice uses, the structured data feed will always be the gold standard. But for the gap — the labs that don't interface, the reports that arrive by fax, the screenshots taken from portals during telehealth visits — this workflow fills a hole that currently requires a human being and a keyboard.

HIPAA and AI Extraction: What Matters and What Doesn't

Any discussion of putting patient lab data through a third-party tool must address HIPAA. The Health Insurance Portability and Accountability Act doesn't mention AI — the statute predates modern large language models by decades. But the HIPAA Security Rule (45 CFR Part 164) establishes requirements that apply regardless of the technology used to process protected health information (PHI). Here is what actually matters for AI lab data extraction:

Business Associate Agreement (BAA). Under HIPAA, any vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity must sign a BAA. This is the legal contract that binds the vendor to the same privacy and security standards as the healthcare organization. If an AI extraction tool processes PHI — and lab results with patient identifiers are unquestionably PHI — a BAA must be in place. This is non-negotiable. Without a signed BAA, sharing PHI with any third-party tool is a HIPAA violation, regardless of the vendor's technical security measures.

Encryption in transit and at rest. The Security Rule requires that ePHI (electronic protected health information) be encrypted both during transmission and while stored. TLS 1.2 or higher for data in transit; AES-256 for data at rest. The tool must not store PHI on unencrypted volumes or transmit it over unencrypted connections.

Zero data retention for model training. This is the AI-specific requirement that didn't exist when HIPAA was written but is now one of the most important questions to ask. Many AI platforms — including consumer-grade tools like the free version of ChatGPT — retain prompt data for model improvement. Sending PHI to a tool that trains on user input is not just a policy issue; it's a reportable breach. The BAA should explicitly prohibit the vendor from using PHI for model training. The vendor's data retention policy should specify that submitted documents are deleted immediately after processing — not stored for 30 days, not retained in logs, not used to improve the model.

Minimum necessary standard. HIPAA requires that only the minimum necessary PHI be disclosed for a given purpose. For lab data extraction, this means the AI should only receive the document images — not the full patient record. The clinical workflow should verify that extracted values are accurate before committing them to the EHR.

Audit logging. HIPAA requires covered entities to maintain audit trails of PHI access. For AI extraction, this means logging which user submitted which documents, when, and what was extracted. The logs must be encrypted at rest, access-controlled, and retained for a minimum of six years from the date of creation.

What doesn't matter — the "HIPAA compliance" label. There is no such thing as a HIPAA-certified product. The Department of Health and Human Services does not certify software. A vendor claiming "HIPAA compliant" means they believe their product can be configured to meet HIPAA requirements — it doesn't mean their default configuration meets them. The only things that matter are: will they sign a BAA? What encryption do they use? Do they train on your data? Where is data stored and for how long? Every other claim is marketing.

Beyond Lab Reports: The Broader Case for AI Medical Data Extraction

Lab results are the highest-volume use case, but they're not the only document type where the screenshot-to-data gap exists. Radiology reports from imaging centers that don't interface with the practice's EHR. Pathology reports from hospital-based labs that send results via a patient portal rather than a direct HL7 feed. Discharge summaries from a hospital in a different health system. Referral letters with attached lab values that the receiving practice needs to trend over time. In each case, the data is already digital in someone else's system — but arrives at your system as an image.

The same semantic extraction approach that reads a CBC from a screenshot also reads a radiology impression from a discharge summary. Define the columns you need — "Study Type, Body Part, Impression, Recommendations, Referring Physician, Date" — and the AI locates each piece of information across documents with radically different layouts. For aggregating radiology and discharge data across patient cohorts, this eliminates the manual abstraction step entirely.

What makes this fundamentally different from the status quo isn't just speed. It's that the extraction doesn't depend on the document's format. A screenshot from Cerner's patient portal looks different from a screenshot from Epic's MyChart. A PDF lab report from Quest uses a different layout than a PDF from LabCorp. But the AI doesn't care — it reads for meaning, not position. That's the difference between a tool that works for one well-defined pipeline and a tool that works for the fragmented reality most practices actually inhabit.

For practices already exploring AI for clinical documentation — whether ambient scribes for visit notes or automated coding for billing — adding lab data extraction to the automation stack eliminates the most repetitive remaining manual task in the clinical workflow. It's not replacing clinical judgment. It's replacing the 10 minutes of keyboarding between the moment the result arrives and the moment a provider can look at it and decide what to do.

FAQ

Can AI extraction handle handwritten lab annotations?

Yes — within limits. The AI can recognize handwritten values, notes, and checkmarks on lab reports such as a pathologist's handwritten addendum or a physician's circled abnormal value. However, extremely cursive or illegible handwriting will have lower accuracy than printed text. The extraction confidence is highest for printed lab values — the handwritten elements should be spot-checked during the review step.

Does this replace the need for an HL7 lab interface?

No. A properly configured HL7 interface that delivers structured lab data directly into your EHR's discrete fields is the gold standard and should remain the goal for high-volume reference labs. AI screenshot extraction fills the gap for labs and reports that can't or won't be integrated — the faxes, the portal screenshots, the PDFs from referring physicians. Think of it as the bridge between "we should build an interface" and "we have patients to see today."

What happens if a lab report is in a language other than English?

The AI can extract numeric lab values from reports in any language — a sodium of 138 mmol/L is the same number regardless of whether the report header says "Sodium" or "Natrium." Test names, units, and reference ranges in other languages are also extracted. For multilingual practices or practices near national borders that receive lab results from both US and international facilities, this avoids the need to translate before extracting.

How accurate is the extraction for abnormal flags and reference ranges?

The AI captures abnormal flags ("H," "L," asterisks, bold text, color coding) and reference ranges as part of the extraction. A verification step — reviewing the extracted spreadsheet against the original report — is recommended for clinical use. The review takes 30 to 60 seconds per report versus 5 to 10 minutes for full manual entry, preserving the time savings while adding a clinical safety check.

Can I use this for STAT lab results?

STAT results should be acted on immediately through whatever channel they arrive in — usually a phone call from the lab or a push notification in the EHR. AI extraction adds 5 to 10 seconds of processing time, which is fast enough for routine and urgent results but should not be the sole mechanism for receiving critical values that require immediate clinical action. Use it to get the data into structured form after the clinical decision has been made.

Last updated: June 23, 2026