Laboratory Partner ServicesGuide
Diagnostic Program service assignment and compatibility
Exact active laboratory Program versions, independent channel/payment models and review-only service readiness.
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.
Select a real Diagnostic Program
The picker uses the existing laboratory testing Program identity, exact tenant/environment, active status and positive version. Membership cadence is unrelated. If the reader fails or version is missing, the selector is disabled and no demonstration Program is used as an actual record.
DTC is a distribution channel; cash_pay is a payment model. They are not mutually exclusive. Assignment requests carry programId, programVersion, connectionId, capability, channels, paymentModels and idempotencyKey within the authorized laboratory scope.
Proposal and operator decision
A laboratory administrator may propose a service and withdraw its own proposal under the staged authority; it cannot approve. Operator decisions are version-fenced. Approved metadata requires a program_service_eligible connection, exact current active Program and independent compatibility/technical proof.
Assignment states are proposed, under_review, approved, blocked, consent_required, revoked, expired and withdrawn. Source proposal never changes Catalog, collection defaults, Fulfillment, DTC pricing or activation. Approved assignment metadata still returns grantsOrdering=false.
Read-only compatibility proof
The bounded compatibility contract binds tenantId/environment, Program ID/version, connection ID/version, assignment ID/version, provider and capability, evidence reference and effective period. Refreshing reads, mismatched IDs, expired evidence, missing adapters and ambiguous assignments refuse readiness.
Outcomes are not_installed, not_configured, evidence_missing, approved_specific_program_only and blocked. The strongest outcome is evidence description for one Program only; executionAuthorized, productionAuthorized, accession and resultRelease remain false.
Reuse canonical methods without expansion
Collection compatibility composes the existing effective Fulfillment resolver: enabled laboratory methods only, item overrides only narrow, and self_kit must be explicitly selected at both laboratory and item level. Method-specific regions never expand from a generic provider claim.
Clinical services require independently reviewed provider authorization. Device collection requires explicit clinical, specimen and device compatibility. Kits require assembly plus inventory evidence; outbound and return legs require their own proof. No combination implies specimen receipt or clinical release.
Revocation and stale versions
Before describing approval, re-read the current connection and assignment state/version plus active Program and evidence window. A stale Program, suspended/expired/revoked connection or incompatible specimen is blocked even if historical metadata was approved.
Suspension/revocation changes only the selected connection’s nonterminal children, increments each child version and appends actual old-state/operator/evidence history. This does not delete prior reviews or alter unrelated Program services. Operational execution remains a separate canonical decision.