Connected to the systems around the laboratory
Every capability on this page carries a status. Nothing is listed as live because it would look better if it were — a laboratory planning an implementation deserves to know exactly what exists today.
Three statuses, used honestly
The capability exists in the platform today.
On the roadmap. Not shipped. Do not plan against it.
Real engineering work, scoped per counterparty.
We state what is live and what is not
Every capability on this page carries a status. A capability marked coming soon is on the roadmap and has not shipped; a capability marked custom is real engineering work scoped per counterparty.
Interfaces are scoped before they are promised
What is possible with a given EMR, instrument or reference laboratory depends entirely on what that system exposes. We establish that first and tell you what it means for scope and schedule.
Failures surface, they do not disappear
Messages that fail to process queue with the reason attached. An unmapped test code or a malformed message becomes a visible exception rather than a silent gap discovered weeks later.
Access is scoped and attributed
API credentials are issued per consumer and scoped to a laboratory or a group. Requests are attributed, and unregistered consumers are refused.
What can connect, and how
EMR / EHR
Connect laboratory workflows to the clinical systems your ordering providers already use.
EMR connectivity is scoped per system. What is possible depends on what the specific EMR exposes — an interface engine, an HL7 feed, a vendor API programme or a file drop — so we establish that first and state the constraints before committing to a schedule.
- Custom integration
Inbound orders from an EMR
Scoped per EMR and per interface method available
- Custom integration
Outbound results to an EMR
Scoped per EMR; delivery is logged on the laboratory side
- Custom integration
Patient demographic synchronization
Where the EMR exposes a suitable feed
- Custom integration
Document attachment to the chart
Depends on the receiving system's document interface
HL7
Support for the healthcare messaging workflows most laboratory interfaces still run on.
HL7 v2 remains the working language of laboratory interfaces. The platform supports the message types that carry laboratory work, with per-counterparty mapping because no two implementations are identical.
- Available
ORM — inbound order messages
Per-counterparty segment and code mapping
- Available
ORU — outbound result messages
Configurable per recipient and per report format
- Available
ADT — patient demographic messages
Used for patient matching and registration feeds
- Available
ACK and error handling
Failed messages queue with the reason visible, not silently dropped
FHIR
A FHIR-ready architecture for modern healthcare interoperability.
The platform's data model is structured with FHIR resources in mind so that FHIR-based exchange can be added per counterparty. We describe this as FHIR-ready rather than FHIR-certified, because certification is a formal process and we do not claim what we have not completed.
- Available
FHIR-ready resource model
Patient, Practitioner, ServiceRequest, Specimen, Observation, DiagnosticReport
- Coming soon
FHIR API endpoints
Scoped per counterparty requirement
- Coming soon
SMART on FHIR app launch
Roadmap item, not shipped
- Coming soon
Bulk data export
Roadmap item, not shipped
Reference Laboratories
Send orders out and bring results back, mapped to your catalog and reconciled on return.
Reference laboratory connectivity is configured per partner: their test codes mapped to your catalog, orders transmitted in their required format, and results imported back against the original accession.
- Available
Reference test configuration and mapping
Per-partner code mapping maintained in the catalog
- Available
Order routing and send-out tracking
Routing driven by rules on the test, not manual choice
- Available
Result import and reconciliation
Imported results matched to the originating order
- Custom integration
A specific reference laboratory connection
Each partner interface is scoped and built individually
Clearinghouses
Eligibility, claim submission, status and remittance for the revenue-cycle workflow.
Billing connectivity runs through a clearinghouse. The platform supports the standard transaction workflow; the specific clearinghouse relationship is configured per laboratory.
- Available
Eligibility transactions
Run inside the order workflow, with exceptions queued
- Available
Claim submission
Configured per clearinghouse relationship
- Available
Claim status
Status followed back onto the claim record
- Available
ERA / remittance processing
Posted and reconciled against expected reimbursement
Laboratory Instruments
An architecture that supports instrument connectivity where it is appropriate.
Instrument interfacing is real engineering work with real variation between analyzers and middleware. The platform is architected to support it, and each connection is scoped as its own project against the specific instrument and its middleware.
- Custom integration
Result ingestion from middleware
Scoped per instrument and middleware platform
- Custom integration
Worklist download to an analyzer
Depends on the instrument's supported interface
- Custom integration
Instrument result reconciliation
Delivered as part of an instrument interface project
APIs
REST APIs for building against the platform directly.
The platform exposes authenticated REST APIs. Access is scoped to a laboratory or granted across a group, credentials are issued per consumer, and every request is attributed — an unrecognized consumer is refused rather than served.
- Available
Authenticated REST API
Per-consumer credentials with organization scoping
- Available
Order and patient endpoints
Create, retrieve and update within the consumer's scope
- Available
Document upload endpoint
Documents routed into the correct laboratory's intake queue
- Coming soon
Webhooks and event subscriptions
Roadmap item, not shipped
Platform services
Integration traffic runs against dedicated platform services rather than a single monolithic endpoint. Credentials are issued per consumer and scoped to an organization; an unregistered consumer is refused rather than served.
entry.getlabservices.comDocument and order intake for external systemsverify.getlabservices.comRecord detail, page images and review actions
What is HL7?
Why laboratories still run on it, and where interfaces break.
What is FHIR?
What it changes, and what FHIR-ready honestly means.
Custom Development
Interfaces built and maintained against real counterparties.
Reference Laboratories
Order and result exchange at volume.
LIS
The system interfaces connect into.
Security
How API access is authenticated and scoped.
Ready to modernize your laboratory?
Whether you need a complete LIS, billing infrastructure, workflow automation, integrations, or managed operational support, let's build the right solution for your laboratory.