Ten stages, each with its own rules, its own exceptions and its own handoffs. This is the path GetLabServices is built around — and the reason the platform treats intake, testing, delivery and billing as one system rather than four.
Orders reach the laboratory through the portal, an EMR interface, an API call, or as a document — a faxed or scanned requisition. All four paths land in the same order queue rather than four separate inboxes.
Provider
Ordering provider, NPI and the facility the order came from
Patient
Demographics, insurance and prior history if the patient is known
Tests
Test selection against your catalog, with CPT and diagnosis codes attached
What the platform does here
Portal ordering for providers and clinics
EMR/EHR order interfaces over HL7 or API
Document intake for faxed and scanned requisitions
Standing order and recurring order support
Documents are classified and read before a person touches them, so a faxed requisition arrives as a structured draft order.
Read it top to bottom to see where information is created, where it is checked, and where it is reused rather than re-entered.
01Order
A provider places an order.
Orders reach the laboratory through the portal, an EMR interface, an API call, or as a document — a faxed or scanned requisition. All four paths land in the same order queue rather than four separate inboxes.
Provider
Ordering provider, NPI and the facility the order came from
Patient
Demographics, insurance and prior history if the patient is known
Tests
Test selection against your catalog, with CPT and diagnosis codes attached
What the platform does here
Portal ordering for providers and clinics
EMR/EHR order interfaces over HL7 or API
Document intake for faxed and scanned requisitions
Standing order and recurring order support
Documents are classified and read before a person touches them, so a faxed requisition arrives as a structured draft order.
02Requisition
The requisition and its attachments are captured.
Requisitions, insurance cards, ABNs and supporting records are attached to the order rather than filed separately. A multi-patient packet is split into one record per patient.
Document
Original file preserved, page images available for review
Classification
Order form, insurance document, result report or record — identified before processing
Split
A packet holding several patients becomes one draft per patient
What the platform does here
Fax, upload, portal and API document intake
Document classification before anything becomes an order
Per-patient splitting of multi-patient packets
Original document retained and linked to the order
Document type is detected at intake. A results report dropped into an order folder is rejected at classification instead of becoming a phantom order.
03Data Processing
Patient, provider, insurance and test data are captured once.
Extraction pulls the fields off the document; validators check them; anything uncertain is held for review. The data is entered once and reused by every downstream step, including billing.
Extraction
Demographics, provider, payer, member ID and requested tests read from the document
Validation
NPI, date, ZIP and phone checks, plus required-field rules per lab
Matching
Existing patient matched, or a potential duplicate flagged for a person
What the platform does here
Field-level extraction with per-field confidence
Configurable validation rules by laboratory
Patient matching with duplicate detection
Field-level edit history and audit trail
Extraction proposes; validators verify; a human approves. Records that fail a validator or match an existing patient too closely are routed to a review queue rather than pushed through.
04Eligibility
Insurance coverage is checked before the work is done.
Eligibility runs inside the order workflow, not as a separate errand afterwards. Where coverage is unclear or the payer cannot be identified, the order moves to an exception queue with the reason attached.
Payer
Payer identified and normalized from what the document actually said
Coverage
Active coverage, plan and benefit information returned and stored on the order
Responsibility
Estimated patient responsibility surfaced early, not after the claim
What the platform does here
Eligibility verification within the order workflow
Insurance discovery when the patient supplies no payer
Exception queues for unresolved or inactive coverage
Coverage results stored on the order for billing to reuse
Coverage documents are interpreted, payers normalized and missing information flagged. Recommendations are advisory and reviewed by staff before they affect billing.
05Accessioning
The specimen is accessioned and labeled.
The specimen gets its accession number, labels and container assignments. Receipt is recorded, and the specimen's state is tracked from that moment until it is resulted or sent out.
Specimen
Type, container, collection date and time recorded against the order
Barcode
Accession number generated and labels printed to your format
Receipt
Sample-received status recorded with who received it and when
What the platform does here
Accession number generation with configurable formats
Barcode and label printing workflows
Specimen type, container and aliquot tracking
Rejection reasons and recollection workflows
06Testing
Tests are routed to the right workflow.
Test configuration decides what runs in-house and what goes to a reference laboratory. Routing is a rule on the test, not a decision someone has to remember to make.
In-house
Worklists and testing status by department and bench
Reference lab
Send-out created, mapped to the reference lab's test code, tracked to return
Status
Every specimen's current state visible without asking anyone
What the platform does here
Per-test routing rules for in-house versus send-out
Reference laboratory test mapping and order transmission
Send-out tracking with turnaround monitoring
Worklists organized by department, bench or instrument
07Results
Results are entered, imported and verified.
Results arrive by manual entry, by import from a reference laboratory, or through an interface. Verification rules decide what a technologist must review before anything can be released.
Result
Entered, imported or interfaced against the correct accession
Verification
Reference ranges, flags and rules applied; critical values surfaced
Report
Report generated in your laboratory's format with the correct footer and signature block
What the platform does here
Manual result entry with reference ranges and flags
Reference laboratory result import and reconciliation
Critical result workflows with documented notification
Amended results with full version history
08Release
Results reach the people authorized to receive them.
Release is a controlled step, not an automatic one. Delivery preferences are configured per provider and facility, and every delivery is recorded.
Authorize
Release permissions by role, with a record of who released what
Deliver
Portal, EMR interface, fax or download, per the recipient's configuration
Confirm
Delivery logged against the order so nothing is delivered twice or not at all
What the platform does here
Role-based release controls
Per-recipient delivery configuration
Result transmission to EMRs and provider portals
Delivery logging and redelivery
09Billing
The claim is built from the order the laboratory already ran.
Because billing shares the order record, the claim is assembled from data that was captured and validated at intake rather than re-keyed from a report.
Claim
CPT, diagnosis, modifiers and payer assembled from the order
Payer
Submitted through the clearinghouse with status tracked back
ERA & payment
Remittance processed, payments posted, denials queued for follow-up
What the platform does here
Claim preparation, scrubbing and submission
Claim status tracking and denial management
ERA and EOB processing with payment posting
Patient responsibility, statements and cash-pay workflows
Billing work queues are prioritized by what is actually blocking payment — missing information, failed validation, denial patterns — rather than by date order.
10Analytics
The laboratory's performance becomes visible.
Every step above writes to the same data model, so operational and financial reporting is a view of the work rather than a monthly reconstruction of it.
Operations
Volume, turnaround time, pending work and staff productivity
Revenue
Claims, AR aging, denials, payer mix and collection performance
Exceptions
What is stuck, where, and for how long
What the platform does here
Operational dashboards for volume and turnaround time
Revenue-cycle dashboards for claims, AR and denials
Exception and work-queue monitoring
Exports and scheduled reporting
Where time is lost
Most laboratories measure the shortest segment
Turnaround time is usually measured from accession to result — the analytical stretch, which is often the part a laboratory manages best. The hours tend to accumulate before it, in the document queue and in data entry, and after it, between a result being verified and it actually reaching the ordering provider.
Because every stage above writes to the same record, turnaround can be measured per segment rather than as one number — which turns “we are slow” into a specific, fixable claim.
Whether you need a complete LIS, billing infrastructure, workflow automation, integrations, or managed operational support, let's build the right solution for your laboratory.