Lab Orders and Results

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

A video visit that cannot order a strep test or read back a cholesterol panel sends the patient somewhere else to finish their care, and that break is where telemedicine products lose trust. Wiring in labs means speaking two interoperability standards, coding results so your app can flag the abnormal ones, and keeping the whole flow inside the HIPAA compliance boundary — all while a 2021 federal rule pushes results to the patient the moment they post. This article is for the founder, product manager, or clinical lead who needs to scope a lab feature honestly: what the order-and-result loop actually involves, which standards and vendors carry it, and where the compliance and patient-safety landmines sit.

The loop: an order out, a result back

Strip away the jargon and a lab feature is a loop. A clinician decides a patient needs a test, your app sends that request to a laboratory, the lab runs the specimen, and the result travels back into your app — ideally landing in the same record and the same consult the order came from. Everything else is detail about how each hop is formatted, coded, secured, and shown.

The request that starts the loop is called an order (clinicians say "CPOE," computerized provider order entry, but it is just the electronic version of writing a test on a pad). The order names the patient, the test, the ordering clinician, and where the specimen will be collected. The lab acknowledges it, collects or receives the specimen, runs it, and returns a result — the measured value, the unit, the normal range, and a flag if the value is out of range.

Two hops carry real risk, and naming them now saves confusion later. The first is matching: the result that comes back must attach to the right patient and the right original order, or a normal potassium for one patient becomes a dangerous mystery value on another chart. The second is the return path into your record, because a result that arrives as a flat PDF instead of structured data cannot be flagged, trended, or searched — it is an image of information, not information.

Figure 1. The lab loop. Your app sends a structured order to a laboratory through a lab network; the lab returns a coded result that lands back in the consult and the patient record. Every hop carries Protected Health Information and needs a Business Associate Agreement.

The two standards that carry it: FHIR and HL7 v2

Labs and records talk to each other in one of two languages, and a telemedicine product usually meets both.

The modern one is FHIR (Fast Healthcare Interoperability Resources, pronounced "fire") — a web-style standard where each clinical fact is a small JSON object called a resource, fetched and posted over ordinary HTTPS APIs. In FHIR, a lab order is a ServiceRequest resource; the returned result is a DiagnosticReport resource that groups one or more Observation resources, with each Observation holding a single measured value. The report points back at the order it answers through its basedOn field, which is the standard's built-in solution to the matching problem above.¹² If your platform already does any EHR integration over HL7 FHIR, labs reuse the same machinery.

The older one is HL7 v2 — a pipe-and-caret text message format from the 1990s that still moves the majority of real-world lab traffic. Here the order is an OML message, the lab acknowledges with an ORL, and the result comes back as an ORU message (you will also meet the legacy ORM order message in older interfaces).³ HL7 v2 is unglamorous and very much alive; a lab feature that cannot speak it will be turned away by a large share of laboratories. Treat FHIR as where the industry is going and HL7 v2 as where much of it still is — and budget for both.

LOINC, units, and why coding is the whole game

A result is only useful if your software knows what was measured. "Glucose" typed as free text is a label; your app cannot reliably flag it, trend it, or compare this lab's glucose to last month's from a different lab. The fix is a shared code for each test, and the standard for that is LOINC (Logical Observation Identifiers Names and Codes), a free universal vocabulary maintained by the Regenstrief Institute that gives every lab observation a stable identifier.⁴ When a result says "LOINC 2345-7," any system in the country knows that is serum glucose, regardless of how the lab labeled it locally.

LOINC says what was measured. Two companion standards finish the picture. UCUM (Unified Code for Units of Measure) standardizes the unit, so milligrams per deciliter are written the same way everywhere and your app does not confuse mg/dL with mmol/L. And for results that are words rather than numbers — "positive," "negative," "detected" — SNOMED CT provides coded values. The United States Core Data for Interoperability, the federal baseline data set every certified record must support, specifies exactly this combination for lab data: LOINC for the test, UCUM for quantitative units, SNOMED CT for qualitative results.⁵ Certified health IT is required to use LOINC for the electronic exchange of lab results, so this is not a style choice — it is the floor.⁵

Figure 2. One coded result, three vocabularies. LOINC names the test, UCUM standardizes the unit on a numeric value, SNOMED CT codes a word result, and the lab's reference range decides whether the value is flagged abnormal.

It is all PHI: the compliance boundary

A test name attached to a patient reveals a health condition, which makes the entire lab flow Protected Health Information (PHI) — any health data tied to an identifiable person — and pulls it inside the same HIPAA rules that govern the rest of your telemedicine platform. The practical consequence is the Business Associate Agreement (BAA), the signed contract that lets an outside party handle patient data on your behalf. The laboratory, any lab network you route through, and any cloud service that stores the result are all business associates, and each needs a BAA in place before a single real result moves.

Keep two ideas separate, because conflating them is the classic error. Encryption protects a result while it travels; the BAA is the legal permission to send it at all. A lab API can be perfectly encrypted and still be a HIPAA violation if you are using it without a signed agreement. If you have not mapped which vendors in your stack are business associates, our BAA explainer and the broader HIPAA guide for telemedicine product teams are the place to start.

There is also a CLIA wrinkle worth knowing. Clinical laboratories are regulated under the Clinical Laboratory Improvement Amendments (CLIA), and a 2014 federal rule amended both CLIA and the HIPAA Privacy Rule to give patients the right to get completed test reports directly from the lab on request, removing an older exception in 45 CFR §164.524.⁶ That rule is the legal ancestor of today's patient-facing results — and a reminder that results were always destined for the patient's hands, not just the clinician's.

The 2021 rule that reshapes the feature: immediate release

Here is the requirement that surprises teams and changes the design. Under the information-blocking rule created by the 21st Century Cures Act, a health care provider may not unreasonably interfere with a patient's access to their own electronic health information — and since the rule became applicable to providers on April 5, 2021, that has meant lab results generally must be released to the patient as soon as they are available, often in parallel with the ordering clinician seeing them.⁷ In 2024 the government finalized the disincentives that apply to providers who commit information blocking, giving the rule real teeth.⁸

The blunt implication: the comfortable old workflow, where a clinician reviewed a result and softened it before the patient ever saw it, is no longer the default. A patient may open a portal notification of an abnormal biopsy result on a Saturday with no clinician available. The rule does include a narrow Preventing Harm exception that lets a provider delay access where release is reasonably likely to endanger the patient or another person — but it is a specific, defensible exception, not a general license to hold results.⁷ Your product has to be built for a world where the patient sees the number first.

Designing for that world is mostly product and clinical-workflow work, not message plumbing. The patterns that hold up: deliver results to the clinician and the patient on parallel tracks rather than gating the patient behind review; attach plain-language context to results the patient will see; route genuinely dangerous values into a real-time clinician alert; and reserve any release delay for the documented Preventing-Harm cases. CLIA already requires labs to alert the ordering clinician immediately for life-threatening "critical" values, so your platform must have somewhere for that urgent call to land even outside a scheduled visit.⁹

Figure 3. How a result should reach people. The default is parallel release to patient and clinician; critical values trigger an immediate clinician alert; a release delay is reserved for the narrow, documented Preventing-Harm exception.

Common mistake: delivering results as PDFs. A lab interface that returns a PDF report "works" in a demo and fails in production. A PDF cannot be flagged abnormal, cannot be trended against last month, cannot be searched, and cannot drive a critical-value alert — it is a picture of a result. Insist on discrete, LOINC-coded results (structured Observations), and treat a PDF-only feed as a stopgap, not the integration. The second classic mistake is hidden next to it: failing to match a returned result to its original order and patient, which a properly used FHIR basedOn link or HL7 v2 order-number echo prevents.

Build versus buy: almost everyone uses an aggregator

You have three honest ways to reach laboratories, and the math points the same direction for most teams.

You can integrate each lab directly — a separate interface to Labcorp, to Quest Diagnostics, to every regional and hospital lab your patients use. Each integration is its own onboarding, its own message profile, its own testing cycle measured in weeks to months, and its own thing to maintain forever. For a national telemedicine product that means dozens of interfaces, which is why almost no one builds this way from scratch.

You can go through a lab-network aggregator — a vendor such as Health Gorilla that has already connected to Labcorp, Quest, BioReference, and hundreds of other labs and exposes one FHIR-based API for ordering and resulting across all of them.¹⁰ You write one integration, sign one BAA, and reach the national networks in weeks instead of quarters. For most telemedicine teams this is the rational default, and it is the same build-versus-aggregator decision covered in depth in our integration decision guide.

You can also let the EHR carry labs — if your product is tightly embedded in a hospital's Epic or Oracle Health system, that record may already own the lab interfaces, and you read results through it. That keeps you out of the lab business entirely but ties you to the host system's pace.

Figure 4. Three ways to reach the laboratories. A direct interface per lab is high-maintenance; one aggregator API reaches hundreds of labs; the EHR can own the interfaces. Every path still requires a BAA.

The table below is the comparison that matters, and like every vendor table in this section it includes the question that decides whether a partner may touch PHI at all.

Vendor coverage, pricing, and supported standards change; confirm the BAA, the current lab network, and structured-result support directly with each partner before you commit.

Where Fora Soft fits in

A lab feature is a compliance and data-quality problem before it is an engineering one, and we scope it that way. When we build telemedicine platforms we treat the lab flow as PHI from the first design session, reach the national networks through a BAA-covered aggregator rather than maintaining a separate interface to every laboratory, and insist on discrete LOINC-coded results so the product can actually flag and trend them. Because we have built real-time video, conferencing, and secure clinical systems since 2005, we wire the order and the result into the same consult, record, and audit trail as one system — so ordering a test and reading it back feels like part of the visit, and the immediate-release rule is handled by design rather than discovered at launch. Lab ordering sits inside the platforms our telemedicine software development company builds, and on AI-assisted products our telehealth platform team connects results to the EHR over FHIR R4.

The handbook

Fora Soft Video Engineering Handbook

We wrote the seven volumes that cover the whole video stack, pixel to production — compression, delivery, sound and AI, across 9,000+ pages. Three of them sit closest to the lab layer described here: the real-time AI volume works through compliance, regulated verticals and what it costs to run a pipeline, which is the same boundary-drawing you do when you decide which outside party may touch a result; the delivery volume covers WebRTC and the real-time transport of the consult the order is placed inside; and the encoding volume explains what the stream and the stored recording actually are, so whatever you write back to a chart is decided on something concrete. Read the series and you can design, price and build a telemedicine platform whose data layer is as deliberate as its video. Written by Nikolay Sapunov, CEO at Fora Soft.

Browse the handbook on Amazon →7 volumes · Kindle & paperback

See our case studies

References