⌘K

Laboratory IntegrationGuide

Laboratory connection

Technical hub for connecting a LIS or LIMS: architecture, transports, contracts, operations and troubleshooting.

On this page

Architecture

text
Laboratory LIS/LIMS
  → Solia connectivity layer (executable HTTPS/JSON; native HL7 v2 / FHIR / SFTP source disabled, not installed)
  → normalized Solia Core (orders, specimens, results, events)
  → Partner API · Standard DTC · Programs

Where the LIS/LIMS fits

Solia owns the ordering channel, catalog, program governance, partner authorization, order lifecycle state, released-result exposure and audit records. The laboratory system remains the system of record for accessioning, analysis and clinical release. The connection is the contract between the two.

text
Solia order queue → HTTPS/JSON order POST → laboratory acknowledgement
Laboratory → accession/specimen/result/report event → Solia lifecycle
Solia released result → Partner API + signed event notification

Supported connection paths

  • HTTPS/JSON Solia Lab Contract — the self-service executable transport available today for outbound orders and authenticated inbound lifecycle events.
  • HL7 v2, FHIR and SFTP/file — managed integration request paths. Native REST, FHIR R4, HL7 v2/MLLP, SFTP and a private-network Edge agent are implemented in source and tested locally, but their runtime is not enabled and no installation is approved. See Connectivity status.

Important

Selecting a managed mode records an integration request; it does not claim that a live interface exists. Production readiness remains blocked until an approved installation and validation evidence genuinely exist. No connection is zero-code or plug-and-play: each requires an installation-specific endpoint, license where applicable, mappings, security review and clinical sign-off.

Owner paths in setup

  • Connect directly — configure the HTTPS/JSON contract yourself.
  • Use existing laboratory system — request a managed HL7 v2, FHIR or SFTP/file integration; Solia coordinates with your technical contact. Translator and conformance packages do not make these transports executable.
  • Use Solia test laboratory — Sandbox only. A real connector proof (order sent, acknowledgement, result received) can complete this setup step, but it is never Production validation; a real Production connection is still required before go-live.

A connection package gives your technical team a non-secret summary of the integration. It never contains reusable credentials or secrets.

What laboratory IT provides

  • A public HTTPS endpoint for connection tests and order receipt, or existing interface specifications for a managed integration.
  • The required authentication method and credentials through the protected configuration flow.
  • Laboratory test codes and mappings for every orderable item.
  • Acknowledgement, accession, specimen-state, result and report behavior for conformance testing.
  • Separate Sandbox and Production endpoints and credentials; Production configuration is never copied from Sandbox.

Transport contract

  • Contract version solia.lab.v1, sent on every request as X-Solia-Contract-Version.
  • Adapter keys: solia-lab-https-sandbox for sandbox connectivity and solia-lab-https for production connectivity — a sandbox adapter can never carry production traffic.
  • Correlation headers: X-Solia-Tenant-Id, X-Solia-Adapter-Key, X-Solia-Transmission-Id and Idempotency-Key.
  • Endpoints on your side: /connection-test for connection testing and /orders for order delivery.
  • Outbound authentication is either Authorization: Bearer <secret> or an API-key header (default X-API-Key).
  • Request timeout 15 seconds; response bodies are read up to 512 KB and inbound bodies up to 1000 KB.

Connection testing and environments

A connection test performs a bounded authenticated request to the contract test path and records whether reachability, authentication and contract-version agreement succeeded. Success is evidence for that exact adapter and environment; it does not activate Production by itself.

Sandbox proves the contract with synthetic data; Production carries live operations. They use separate configurations, credentials and adapters, and outbound DNS is re-evaluated before delivery so a configured hostname cannot resolve to a private destination at send time.

Operational model

  • Outbound request timeout 15 seconds; up to 5 attempts with backoff from 30 seconds to 60 minutes.
  • Idempotency by Idempotency-Key on every order delivery.
  • Inbound events are signed, rejected outside 300 seconds, and rate-limited to 120 per minute per laboratory adapter.
  • Undeliverable transmissions become canonical transmission exceptions on the order; monitor them in Orders and Integrations → Activity.

Troubleshooting

  • Connection test fails on authentication — confirm the auth mode (bearer or API-key header) and credential match what your endpoint expects.
  • Contract version mismatch — your endpoint must accept the current contract version header.
  • Order not transmitted — check for an unmapped orderable (catalog-mapping exception).
  • Inbound event refused — check signature base string, clock skew, correlation identifiers and unknown fields.
  • Endpoint refused at configuration — hostnames must resolve to public addresses over HTTPS.

For support, include the environment, transmission identifier, timestamp and the exception shown — never credentials or patient data.

Reference laboratory engineering boundary

Reference/send-out is source-only and unavailable in Sandbox or Production. Existing integration, buyer, publication and clinical authorities remain unchanged; a directory listing or relationship never authorizes a referral.

Related resources