We already have an interface engine. Do we need anything else?

That depends on what you are trying to serve. An interface engine is built to route and transform messages between systems. A partner-facing program adds different requirements: credential and scope management per partner, a published catalog, serviceability rules, idempotent ordering, a normalized status lifecycle, signed webhooks with retry and replay, and separate Sandbox and Production environments. Some laboratories build that surface themselves on top of the interface engine; Solia Direct provides it as a platform.

How does Solia Direct actually connect to the laboratory?

The self-service path is an HTTPS/JSON connection against the Solia Lab Contract. HL7 v2, FHIR and SFTP are supported as managed integration paths. Mappings between the laboratory's codes and the partner-facing catalog are configured and validated before Production activation.

Does this add another system for laboratory staff to operate?

Solia Direct is operated through one Control Plane that covers Programs, partner access, catalog, orders, results and integrations. It does not change the internal laboratory workflow that runs in the LIS/LIMS.

Can middleware alone support a partner program?

In some cases, yes — particularly for a single long-lived partner with a bespoke interface. The question is usually what happens at the second and third partner, when credential scoping, catalog reuse, serviceability and change management start repeating.

Category comparison

Solia Direct vs. traditional LIS middleware

Q: Is Solia Direct a replacement for our LIS or LIMS?

No. Solia Direct connects to the laboratory's existing systems and operates the reusable commercialization and partner-connectivity layer around them. The LIS/LIMS remains the system of record for testing, specimens and official clinical results.

One runs the laboratory. The other makes the laboratory reusable to partners.

Solia Direct is an operating and connectivity layer for diagnostic laboratories. Connect the laboratory once and reuse that infrastructure across multiple Programs and partners through one Control Plane and Partner API—without replacing the LIS/LIMS.

This is a category comparison, not a vendor takedown. Traditional LIS/LIMS and middleware products are mature, deeply embedded systems that solve a different problem than partner-facing commercialization.

What traditional LIS/LIMS and middleware do.

Public vendor material across this category consistently emphasizes the laboratory's own operations: the specimen journey end to end, analyzer and point-of-care connectivity, multi-discipline and multi-site workflow, and interoperability with hospital information systems, order-entry software and reporting destinations. Capabilities vary by vendor and deployment.

Specimen and workflow operations

Order entry, accessioning, specimen tracking, worklists, batching and turnaround management across disciplines and sites.

Analyzer and device connectivity

Instrument interfaces, result capture, quality control and point-of-care device connectivity inside the laboratory.

Result validation and routing

Autoverification rules, review queues, amendments and corrections, and delivery to ordering systems and reporting destinations.

Standards-based interfaces

HL7 v2, FHIR, file transfer and interface-engine connections to hospital information systems, EHRs, order-entry software and reporting systems.

What Solia Direct does above them.

Solia Direct assumes the laboratory already runs well internally. Its concern is the layer that faces outward: how an approved partner discovers what the laboratory offers, places a valid order, tracks it and receives results — repeatably, across Programs.

Programs and partner access

A reusable Program model with scoped grants, so an authorized partner reaches only the capabilities the laboratory has approved.

Partner-facing API

One HTTPS/JSON Partner API for catalog, serviceability, ordering, status, results and signed webhooks — the same surface for every Program.

Commercialization layer

Catalog definition, serviceability rules, environments and partner operations that turn existing testing capacity into an offering partners can consume.

Environments and readiness

Sandbox with synthetic data for integration work, and separately gated Production activation driven by readiness rather than a self-serve switch.

Internal connectivity and external connectivity are different problems.

Internal connectivity answers: did this specimen reach the right analyzer, did the result validate, did it route to the ordering system. It is optimized for correctness inside a controlled environment.

External connectivity answers a different set of questions: which partner is calling, what have they been granted, what can they order in this geography, is this order idempotent, what does the status mean to someone who does not work at the laboratory, and how do they get told when it changes.

The overlap is real — both move orders and results. The distinction is primarily who is on the other end of the interface, and how many of them there will be.

At a glance

Category-level comparison. Traditional LIS/LIMS and middleware capabilities vary significantly by vendor, version and deployment.

Comparison between Solia Direct and traditional LIS/LIMS middleware across positioning, connectivity direction, Programs, catalog, serviceability, orders, results and environments
Dimension	Solia Direct	Traditional LIS/LIMS & middleware
Primary job	Operate the reusable commercialization and partner-connectivity layer around the laboratory.	Operate and connect the laboratory's own systems, instruments and clinical workflow.
Where it sits	Above the LIS/LIMS and interface engine, facing Programs and partners.	Inside the laboratory, between analyzers, the LIS/LIMS and connected clinical systems.
Direction of connectivity	Primarily external — partners and Programs consuming laboratory capability.	Primarily internal and institutional — instruments, hospital systems, EHRs and reporting destinations.
Consumer of the interface	Partner engineering teams integrating against a documented Partner API.	Laboratory staff, instruments, and institutional interface projects.
Program model	Multiple Programs reuse one laboratory connection with per-Program configuration and grants.	Category capabilities vary; interfaces are typically configured per connected system or client.
Catalog	Partner-facing catalog mapped to the laboratory's test codes and reused across Programs.	Internal test dictionary, panels, profiles and analyzer mappings used to run the laboratory.
Serviceability	Geography, collection model and clinical requirements expressed per Program for partners.	Handled operationally and through client configuration rather than as a partner-facing API concept.
Orders and results	Normalized order lifecycle and result delivery exposed to partners, derived from the laboratory's systems.	Authoritative order, specimen and result records, validation and clinical release.
Events	Signed webhooks with retry and replay for partner systems.	Interface-level messaging and routing, typically HL7 v2 or file-based.
Environments	Sandbox with synthetic data and separately gated Production.	Test and production instances are common; capabilities and provisioning vary by vendor.
System of record	Not the system of record. Does not perform testing or author clinical results.	The laboratory's system of record for testing, specimens and official results.

Primary job

Solia Direct

Operate the reusable commercialization and partner-connectivity layer around the laboratory.