Lab ordering API vs portal vs manual orders: how digital health companies integrate lab testing
Digital health companies usually connect to a lab in one of three ways: manual orders (paper or PDF requisitions), a web portal where staff key in orders, or an API that sends orders and receives results automatically. Manual and portal ordering suit pilots and low volume. An API makes sense once volume, speed and data quality matter more than setup time.
Most teams don't pick a method once and keep it forever. They start simple, learn where orders break, and add automation where it pays off. This guide walks through how each option works, what it costs you in effort, and how to decide which one fits your program today.
This article is educational only, not legal or technical advice. Check the details with your own compliance and engineering leads.
What every lab order needs, whatever the channel
Whichever method you use, the lab still needs a complete, valid order. Under the federal CLIA rules, a lab must have a written or electronic test request from an authorized person, and the requisition has to capture details such as:
Who ordered the test, with contact details for urgent or critical results
The patient's name or unique identifier
Sex and age or date of birth
The tests to be performed
The specimen source, when relevant
The collection date and, when relevant, the time
The same rule says that when a lab transcribes order information into its own system, it has to do so accurately. That is the real difference between channels. Each method moves the same information, but some rely on people retyping it and others pass it system to system.
Option 1: manual orders
Manual ordering means a clinician or coordinator fills out a paper or PDF requisition, and it travels with the specimen or is sent to the lab separately. Results come back by fax, email or a results portal.
Where it works:
Pilots with a handful of patients a week
Occasional specialty tests outside your normal panel
Backup when another channel is down
Where it breaks:
Missing or illegible fields, which delay testing
Mismatches between the requisition and the specimen label
Results that someone has to download, file and chart by hand
No real-time view of where a kit or sample is
Manual orders cost almost nothing to set up, but the cost shows up later as staff time and rework.
Option 2: a lab web portal
With a portal, your team logs in to the lab's website, enters orders, and sees status and results there. Many labs offer this as the default way for clinics and small programs to get started.
Where it works:
Early-stage telehealth or wellness programs with modest daily volume
Teams without engineering time to spare
Programs that want structured order entry and online result access without building anything
Where it breaks:
Your own platform and the lab portal hold separate copies of patient data, so staff copy between them
Order status lives in the lab's system, not in your app, so patient support teams switch screens to answer "where's my kit?"
Volume growth means more staff time per order, not less
A portal is a solid middle step. It cuts handwriting and fax errors, but it doesn't remove double entry.
Option 3: a lab ordering API
An API lets your software talk to the lab's software directly. Your platform creates the order, the lab ships a kit or expects a specimen, status updates flow back, and structured results land in your system without anyone retyping them.
What a good lab API typically covers:
Creating orders with patient, ordering-provider and test details
Kit fulfillment and shipment tracking, when the lab ships kits
Specimen receipt, plus rejection with a reason when a sample can't be run
Results as structured data (values, units, reference ranges, flags), not just a PDF
Notifications, through polling or webhooks
A test or staging environment with mock results
Where it works:
Telehealth platforms ordering labs as part of a visit flow
Programs shipping at-home kits at scale
Products that show results, trends or follow-up actions inside their own app
What it costs you:
Engineering time to build, test and maintain the integration
Security reviews, key management and monitoring
A clear plan for errors, such as rejected specimens, cancelled orders or corrected results
Many lab APIs model their data on HL7 FHIR, the health data standard. In FHIR terms an order is a ServiceRequest and a result is a DiagnosticReport with linked observations. If your platform already uses FHIR, an aligned lab API will be easier to map.
What about EMR integrations?
Clinics and practices often skip all three and order through their electronic medical record. The EMR sends orders to the lab and receives results back, usually over an HL7 interface the lab and EMR vendor have set up. For a clinic, that's often the best option, because clinicians stay in one system. For a digital health company that built its own platform, an API usually fits better than trying to act like an EMR.
How to choose: a quick decision guide
Ask these questions in order:
What's your volume? A few orders a week rarely justifies an integration. Hundreds a week usually does.
Where do patients see results? If results must appear in your app, you need structured data, which points to an API.
Who answers "where's my kit?" If your support team needs live status, you want status events in your own system.
Do you have engineering time? If not, start with a portal and plan the API for later.
How often does your test menu change? Frequent panel changes favor a channel where updates are easy to manage on both sides.
What happens on a bad day? Every channel needs a defined path for rejected specimens, critical values and corrected reports.
A common path is portal first, then API. You learn your real order patterns on the portal, then build the integration around what you've seen.
Questions to ask a lab about its integration options
Before you commit, ask the lab:
Which ordering channels do you support, and can we use more than one at once?
Is there a sandbox with realistic mock results for our panel?
Do you send status updates for shipment, receipt, rejection and results?
Are results delivered as structured data with reference ranges?
How are API requests authenticated, and how are webhooks secured?
What does onboarding look like, from first call to going live?
Clear, specific answers here tell you as much about a lab partner as its test menu does. For a broader vetting list, see our guide on how to choose a white-label lab testing partner, and for platform-side planning, what telehealth platforms should ask before adding lab testing.
The bottom line
Manual orders are fast to start and slow to scale. Portals remove paperwork but keep double entry. APIs take real build effort and pay it back as volume grows. Pick the channel that matches where your program is now, and make sure your lab can grow with you.
IHDLab, a CLIA-certified lab in Irvine, California, works B2B with telehealth and digital health companies, which can connect through its LabFlow API or an EMR integration. You can see how LabFlow handles orders, kits and results on the lab integrations page, or explore telehealth lab partnerships.
