⌘K

Laboratory Partner ServicesGuide

Partner Services activation prerequisites and operations

Owner approvals, per-provider pilot dependencies, manual finance safety and publication read-back.

On this page

Availability and evidence boundary — October 25, 2026

Limitation

Laboratory Partner Services is source-only, NOT operational in Sandbox and NOT available in Production. Its staged database package is UNAPPLIED, the service gate remains off and prospective providers are not connected or verified. No partner delivery, clinical execution, invoices, payments or certification are enabled.

The laboratory-only Control Plane presents four separate sections: Explore Services, My Connections, Program Configuration and Activity. Read failures are unavailable evidence, not zero activity or successful requests. Source contracts, disposable persistence, genuine hosted identity, partner acceptance and publication are independent evidence classes.

Current status and stop conditions

All five provider descriptors remain prospective and every operational verification fact is false. Core service authority is missing and the service gate is disabled. The source closeout completes design/test/documentation work only; it is not a live availability or certification announcement.

Do not activate a partner, apply SQL, send a packet, collect credentials, approve clinical use, invoice or publish the shared application as a consequence of reading this guide.

Core and security owner checklist

The Core operator must independently approve dependency scope, role grants, private reader/signing custody, retention, exact package hashes and rollback prerequisites. Security verifies bearer/tenant/environment isolation, no direct laboratory table or ledger access, immutable identities and append-only event history.

Current empty-table rollback refuses to erase evidence once records exist. An operator must preserve records and follow an independently approved forward remediation; source instructions are not permission to truncate or bypass history.

Laboratory and clinical checklist

Name the laboratory and laboratory IT owner, current active Programs/versions/tests, exact collection methods/devices/specimens and service geography. Clinical reviewers own provider authorization, specimen stability, high-risk exclusions, critical-result governance and result-release responsibility.

Shamil/fractional technical lead coordinates integration and genuine acceptance. Laboratory IT owns account scope and interface evidence. Neither technical lead nor finance can sign clinical release or infer a vendor is certified from synthetic tests.

Pilot and publication read-back

A future pilot needs signed lab/provider scopes, independently approved genuine Sandbox policy/identity and evidence from each existing operational system, followed by vendor/security/clinical signoff and deliberate Production authorization. Pausing or revoking metadata cannot erase past business evidence.

Source navigation/search/sitemap and generated developer text must resolve every guide. After a separately authorized release, GET clean documentation-host URLs and compare current availability text, changelog, sitemap and developer index. A 404 or stale page remains unverified propagation; source/build/CI success is not publication and grants no deployment permission.

Related resources