⌘K

Laboratory IntegrationGuide

LIS onboarding, mapping review & installation authority

How a laboratory founder and its IT team identify a laboratory system, review code mappings and reach installation approval inside the six-step onboarding.

On this page

Who does what

  • The laboratory founder (Lab Admin) owns the six-step onboarding: profile, catalog, fulfillment, Sandbox, Connect your laboratory (Step 5) and Production readiness (Step 6). There is no separate IT wizard.
  • Operations members can view the technical handoff in Step 5 and contribute information to the laboratory's IT team, but only a Lab Admin can save owner-facing connection changes. Native dictionary authoring requires separate governed capability; independent review additionally requires a qualified clinical reviewer distinct from the author.
  • Laboratory IT supplies interface specification, endpoint, network path and authentication type through the managed integration request. Never paste credentials into that request; provision them separately through approved secret custody.

Laboratory system selection

Step 5 records which laboratory information system (LIS) the laboratory runs. Selecting a named product marks the stage "Laboratory system identified" — it does not mean a connector is configured, installed or certified.

  • Named products (for example Orchard, Clinisys, Epic Beaker, Sunquest, LabDAQ) map to candidate starting packages only. No vendor package is certified today.
  • Unknown or unlisted systems follow the managed integration path and can continue preparation. Native verification and Production remain blocked until installation authority and approvals exist.
  • The executable path today is the HTTPS/JSON Solia Lab Contract (solia.lab.v1) proven with the Solia Test Laboratory in Sandbox.

Mapping review

  • The site dictionary editor supports bounded orderable, specimen, result and governed-question codes. Persistent authoring is pending installation of its approved authority; local preview is not a saved review. When available, save and rollback create immutable new draft revisions.
  • A source code may map to only one target. Codes that differ only by letter case collide; whitespace is refused rather than normalized. Output units never distinguish one input from another.
  • Every revision requires independent review by a different authorized person. The author cannot approve their own revision.
  • An approved mapping revision is review evidence. It is not permission to send clinical orders.

Installation authority

Limitation

Installation authority — the server-side record that binds one approved connector installation to one workspace and environment — is not yet available in Solia Core. Until it is, native installations cannot be approved and no native order is sent.

When available, an installation must be bound to exactly one laboratory workspace and one environment; installations are never shared across laboratories. See the [installation go-live checklist](/laboratory/installation-go-live).

Step 6: technical versus business activation

  • Technical readiness: the selected connection path has current proof — Sandbox order, acknowledgement and result for HTTPS/JSON — and Production validation has passed.
  • Business activation: plan, payment and a separately approved go-live. Payment never activates Production on its own, and activation is derived on the server and fails closed when any read is missing, failed or stale.
  • After activation, the Partner API handoff appears only when the current activation read is authoritative.

After go-live

  • Sandbox continues to accept synthetic test orders for regression testing.
  • Production integration checks are metadata-only: they confirm configuration and recent evidence and never place a clinical order.
  • Testing against a real laboratory system with synthetic patients stays blocked until the laboratory, clinical and security approvals are recorded.

Related resources