Solia Direct DocsSign In
⌘K
Main siteExplore Sandbox

Laboratory IntegrationGuide

Native REST & FHIR R4 orders and results

Implemented native REST and FHIR R4 order submission and result retrieval, guards, and current gating.

On this page

Status

Limitation

Status today: this interface is implemented in source and exercised only in isolated local tests. Its runtime is disabled, no laboratory installation is approved, and no vendor or product version is certified. It cannot carry Sandbox or Production orders until the release-readiness process in Installation validation & go-live is complete.

Authority and prerequisites

  • Solia Core owns the order, its transmission record and every lifecycle state; the native adapter only executes an already-claimed transmission.
  • The laboratory owns its API or FHIR server, credentials, accessioning and clinical release.
  • Prerequisites: an approved installation bound to one laboratory workspace and one environment, an immutable profile revision, approved code mappings, and a credential held in Solia's secret store — never supplied in a request form.

REST interaction

  • Order: one HTTPS request per transmission to the installation's configured endpoint. TLS certificate and hostname verification stay enabled; redirects are refused.
  • Acknowledgement: only a response that matches the profile's success contract and echoes the expected correlation is treated as accepted. Anything else is a rejection or an ambiguous outcome.
  • Results: retrieved by polling the configured result resource for the correlated order (see Result polling).

FHIR R4 interaction

  • Before any order is sent, the server's CapabilityStatement must declare FHIR R4 and ServiceRequest create. Without it, the order is never submitted.
  • Order bundles must reference a subject and specimen and carry identifiers; incomplete bundles are refused before transmission.
  • Results are normalized from a DiagnosticReport bundle that references the expected ServiceRequest. Supported report states: final, corrected and amended; a report for a different ServiceRequest is refused.
  • Not implemented: SMART backend-services token lifecycle, FHIR subscriptions/callbacks.

Duplicates, retries and ambiguous sends

  • A send is ambiguous when the request may have reached the laboratory but no conclusive response was received. Ambiguous sends are never retried automatically; they surface as an exception for operator reconciliation.
  • Retries apply only to failures where nothing was delivered, up to the transport's bounded attempt limit (5 for HTTPS).
  • If the canonical record of an attempt cannot be written after a possible delivery, the adapter does not acknowledge, retry or report success.
  • Cross-workspace or cross-environment dispatch is refused.

Related resources

Laboratory connectionAdapter FrameworkOrder interface