Laboratory Partner Services architecture

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.

Core owns laboratory identity, Program versions and canonical operational state. Partner Services describes a laboratory-to-business relationship and optional Program service assignment; it does not own a patient order, clinical review, booking, accession, shipment or result. Laboratory services are separate from the Health Company services workspace and from bilateral Reference Testing.

A provider descriptor is not a verified integration. Each descriptor has candidate capabilities, separately planned capabilities and independently false commercial, account, technical, Sandbox, Program and Production verification facts. Neither a logo nor registry membership establishes operational coverage.

The relationship contract version is solia.lab.partner_services.v1. Laboratory reads allow-list relationship identifiers, environment, mode, provider key, category, capabilities, state, version and effective dates. Contact details, account references, evidence attachments and all referral economics are absent from this projection.

Queries and remounts isolate tenantId plus sandbox/production. Canonical testing Program identity, active status and version are read separately through the signed-in laboratory scope. A missing version is not replaced with a mock Program.

Internal request → operator review → independently evidenced human handoff → partner review and decision → account authorization → technical validation → exact Program review. A commercial introduction requires handoff proof; an existing account nomination is a different path and cannot claim an external introduction.

Business approval does not authorize provider ordering. Clinical authorization, specimen/method review, collection geography, effective Fulfillment, installation and release policies remain their existing independent authorities.

OpenLoop is the preferred candidate for provider ordering, clinical review and telehealth. A reported executed referral agreement is not authenticated clause-level evidence here; submission procedure, signatures and fee terms require operator/legal verification before a manual handoff. Speedy Sticks mobile collection is candidate and draw-site expansion is planned separately.

Tasso is a collection-device candidate requiring lab/test/specimen-specific review. DOT legal identity remains unknown. Supera Fulfillment is a kitting and logistics candidate; packaging, inventory, outbound, return and laboratory receipt are separate facts.

Disposable PostgreSQL with loopback PostgREST can exercise request rows, authenticated role enforcement, event retention and revocation using test-signed identities. Those identities are not genuine hosted sign-in. A disposable fixture labeled production is only a state-graph test, never actual Production activation.

The frozen state graph does not allow a complete approved Sandbox connection. Full joined bilateral Sandbox operational acceptance remains PARTIAL; no UI status or compatibility projection relaxes that constraint.