Is building always slower or more expensive?

No. A capable engineering team with a clear, narrow requirement can build a partner interface quickly. The more useful question is total ownership: who maintains credential scoping, catalog versioning, idempotency, correction handling, webhook replay, environment separation and partner change management two years from now, and what else that team is not building during that time.

What does a laboratory still own with Solia Direct?

Its catalog and mappings, its Programs and partner relationships, its commercial terms, its clinical and regulatory responsibilities, and its own systems. Solia Direct does not perform testing and does not replace the LIS/LIMS.

Where does a composable commerce platform fit?

Components such as commercetools can serve as an ordering, pricing or checkout surface inside an internally built or assembled architecture. They are illustrative of Approach A and B rather than a substitute for the diagnostic domain model — catalog capability, serviceability, specimen requirements, order lifecycle and result handling still have to be authored.

Can we start with Solia Direct and build later?

The Partner API and Control Plane are the integration surface; the laboratory's own systems and data remain its own. Laboratories commonly evaluate in Sandbox first, with synthetic data, before committing to a production path.

How do we estimate the build honestly?

Scope it against the ownership list on this page rather than against a single partner integration. The first partner is rarely where the cost lives; the second and third partner, and the first correction or outage, usually are.

Does Solia Direct require replacing anything?

No. It sits above the existing LIS/LIMS and interface layer and connects to them.

Architecture decision

Build your own laboratory API and integration layer — or deploy Solia Direct?

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 page is about ownership, not persuasion. Building is a legitimate choice. The decision is which parts of a partner-facing integration surface your team wants to own permanently.

What "build" actually means owning.

Almost every laboratory that evaluates this can build the first partner integration. The scope that decides the answer is what surrounds it.

Partner access

Authentication, credential issuance and rotation, scopes, Program grants, and revoking access cleanly when a partner relationship ends.

Catalog

A normalized test capability model mapped to laboratory codes, with panels, specimen requirements and versioning as the catalog changes.

Serviceability

Geography, collection model, clinical requirements and eligibility rules expressed programmatically rather than in an operations spreadsheet.

Order lifecycle

Validation, idempotency, routing, identifier management and a status lifecycle that means the same thing to every partner.

Result lifecycle

Normalization, corrections and amendments, delivery, and the distinction between an operational status and an official clinical result.

Events

Signed webhooks, retry policy, replay, dead-letter handling and giving partners a way to recover after their own outages.

Environments

Separate Sandbox and Production credentials, synthetic data, and a readiness process that gates live activation.

Laboratory interfaces

Mappings, laboratory codes, LIS/LIMS interfaces, HTTPS/JSON connections and HL7 v2, FHIR or SFTP paths where applicable.

Operations

Observability, reconciliation, on-call, change management and versioning as partners and the catalog evolve.

Program model

A reusable abstraction so the second and third Program do not each become a fresh integration project.

Three credible approaches.

Approach A

Build internally

An internal engineering team designs and operates the partner-facing API, the normalization layer and the connection into the LIS/LIMS. The laboratory owns every item in the list above, permanently.

Maximum control and maximum fit. The cost is not only the initial build but the ongoing ownership of a production integration surface that external partners depend on.

Approach B

Assemble components

Point solutions are combined — an API gateway, an identity provider, a workflow engine, a data platform, an interface engine, and in some architectures a composable commerce component such as commercetools for the ordering and pricing surface.

Individual components are mature. The integration logic between them, and the diagnostic-specific domain model, remain the laboratory's to build, test and maintain.

Approach C

Deploy Solia Direct

The laboratory connects its infrastructure once and configures Programs, catalog, serviceability and partner grants through the Control Plane. Partners integrate against the documented Partner API.

The reusable surface is provided rather than authored. The laboratory still owns its catalog decisions, mappings, commercial terms and its own systems.

Ownership, line by line

"Build internally" covers Approaches A and B, which differ in how much is purchased as components rather than written.

Comparison of operational ownership between deploying Solia Direct and building a laboratory API and integration layer internally
Dimension	Deploy Solia Direct	Build internally
Partner authentication and scopes	Provided. Credentials, scopes and Program grants are configured in the Control Plane.	Designed, built and operated internally, including rotation and revocation.
Catalog normalization	Provided model; the laboratory owns the mappings and catalog decisions.	The capability model itself must be designed, then maintained as the catalog changes.
Serviceability rules	Configured per Program as a first-class concept.	Built as custom rules, or handled operationally outside the API.
Order validation and idempotency	Provided as part of the Partner API contract.	Owned — including duplicate handling, identifiers and edge cases under partner retry behaviour.
Status lifecycle	One normalized lifecycle shared across Programs and partners.	Defined internally, and typically renegotiated with each new partner.
Result delivery and corrections	Normalized delivery with correction and amendment handling.	Owned, including how corrections propagate to partners who already received a result.
Webhooks, retries and replay	Signed webhooks with retry and replay.	Owned, including the failure modes that only appear once partners are live.
Sandbox and Production	Sandbox with synthetic data; Production separately gated and readiness-driven.	Environment separation, synthetic data and readiness gating are built internally.
LIS/LIMS connection	HTTPS/JSON self-service against the Solia Lab Contract; HL7 v2, FHIR and SFTP as managed paths.	Built and maintained per interface, with the laboratory's own engineering on both sides.
Observability and reconciliation	Order, result and integration visibility in the Control Plane.	Instrumented internally, including reconciliation between partner records and laboratory records.
Adding the next Program	Configured against the existing connection and grant model.	Depends entirely on how reusable the first build turned out to be.
Change management	Platform versioning and documented API changes.	Owned, including deprecations communicated to every integrated partner.
Control and customization	Configuration within a defined platform model.	Unconstrained — any behaviour the laboratory is willing to build and operate.

Partner authentication and scopes

Deploy Solia Direct

Provided. Credentials, scopes and Program grants are configured in the Control Plane.

Build internally

Designed, built and operated internally, including rotation and revocation.

Catalog normalization

Deploy Solia Direct

Provided model; the laboratory owns the mappings and catalog decisions.

Build internally

The capability model itself must be designed, then maintained as the catalog changes.

Serviceability rules

Deploy Solia Direct

Configured per Program as a first-class concept.

Build internally

Built as custom rules, or handled operationally outside the API.

Order validation and idempotency

Deploy Solia Direct

Provided as part of the Partner API contract.

Build internally

Owned — including duplicate handling, identifiers and edge cases under partner retry behaviour.

Status lifecycle

Deploy Solia Direct

One normalized lifecycle shared across Programs and partners.

Build internally

Defined internally, and typically renegotiated with each new partner.

Result delivery and corrections

Deploy Solia Direct

Normalized delivery with correction and amendment handling.

Build internally

Owned, including how corrections propagate to partners who already received a result.

Webhooks, retries and replay

Deploy Solia Direct

Signed webhooks with retry and replay.

Build internally

Owned, including the failure modes that only appear once partners are live.

Sandbox and Production

Deploy Solia Direct

Sandbox with synthetic data; Production separately gated and readiness-driven.

Build internally

Environment separation, synthetic data and readiness gating are built internally.

LIS/LIMS connection

Deploy Solia Direct

HTTPS/JSON self-service against the Solia Lab Contract; HL7 v2, FHIR and SFTP as managed paths.

Build internally

Built and maintained per interface, with the laboratory's own engineering on both sides.

Observability and reconciliation

Deploy Solia Direct

Order, result and integration visibility in the Control Plane.

Build internally

Instrumented internally, including reconciliation between partner records and laboratory records.

Adding the next Program

Deploy Solia Direct

Configured against the existing connection and grant model.

Build internally

Depends entirely on how reusable the first build turned out to be.

Change management

Deploy Solia Direct

Platform versioning and documented API changes.

Build internally

Owned, including deprecations communicated to every integrated partner.

Control and customization

Deploy Solia Direct

Configuration within a defined platform model.

Build internally

Unconstrained — any behaviour the laboratory is willing to build and operate.

The two architectures side by side.

Build internally

Partners

Each with its own integration agreement

Internally built APIs and workflows

Auth · Catalog · Orders · Results · Events

Custom normalization and routing

Mappings · Validation · Reconciliation

LIS/LIMS

System of record

Each partner relationship tends to add surface area to maintain.

Deploy Solia Direct

Programs and partners

Lab-owned · Partner-led · Optional consumer experience

Control Plane + Partner API

Grants · Catalog · Serviceability · Orders · Results · Webhooks

Solia operating and connectivity layer

Normalization · Mappings · Environments

LIS/LIMS

System of record

One connection is reused across Programs and partners.

When building may be the right choice.

Building is often the correct decision. It tends to fit when a laboratory:

Has a dedicated engineering team with capacity beyond the initial build
Has requirements that genuinely differ from a standard partner-facing model
Serves a small number of long-lived partners with stable interfaces
Treats the integration layer as a strategic asset it intends to own
Already operates production APIs with on-call, versioning and change management
Needs behaviour that no platform model would allow it to express

When Solia Direct may fit.

Deploying the layer tends to fit when the laboratory's constraint is time, repeatability or engineering focus rather than capability. It may fit when a laboratory wants to:

Add Programs and partners without a new integration project each time
Give partners a documented API, scoped credentials and signed webhooks on day one
Separate Sandbox integration work from gated Production activation
Keep engineering focused on laboratory operations rather than partner plumbing
Reuse one laboratory connection across multiple Programs
Keep the existing LIS/LIMS in place unchanged

Frequently asked questions

Sources and disclosure

The effort, architecture and total ownership of an internal build depend on the laboratory's existing systems, engineering capability and requirements. Nothing on this page should be read as a claim that building is universally slower or more expensive.

References to composable commerce architecture reflect publicly available vendor documentation reviewed in September 2026 and are illustrative of a component within an internally built or assembled architecture. Solia Direct is not affiliated with, endorsed by or sponsored by any vendor named on this page.

Related comparisons

Solia Direct vs Luminate Health

Luminate Health publicly emphasizes patient engagement, provider engagement, direct-to-consumer testing and population-health applications built around laboratory data. Solia Direct is a reusable operating and connectivity layer that exposes laboratory capabilities across multiple Programs and partners.

Read comparison

Solia Direct vs Junction

Junction publicly presents diagnostic and device infrastructure that healthcare and digital-health companies use to order testing and retrieve results through one API. Solia Direct starts from the laboratory side, so the laboratory connects its own infrastructure once and exposes it through Programs, a Control Plane and a Partner API.

Read comparison

Solia Direct vs Traditional LIS Middleware

Traditional LIS/LIMS and middleware operate and connect the laboratory's internal systems — accessioning, analyzers, validation, routing and standards interfaces. Solia Direct operates the reusable commercialization and partner-connectivity layer around those systems.

Read comparison

See every comparison on the Compare Solia Direct hub.

Scope it against your own build estimate.

Bring your architecture, your partner requirements and your internal estimate. We will walk the same ownership list against both paths.

See the architecture