Aidbox tenants need explicit FHIR-version boundaries

Declare the contract at the tenant boundary

The direct answer is to make each tenant and environment publish an explicit interoperability contract. Record tenant and environment identifiers, deployment version, base FHIR release, canonical endpoint, implementation-guide package and version, dependency graph, profiles, extensions, search behavior, terminology packages, authorization pattern, supported interactions, effective date, migration state, and accountable owner. A platform's ability to support several releases is not evidence that a client can mix them safely or that an endpoint implements all of them.

Keep development, test, validation, and production separate. Health Samurai's page distinguishes a development offering from production-oriented deployment options and describes cloud, customer-cloud, and on-premise paths. Configuration and artifact state can differ across those environments even when product branding is identical. Promotion should create a receipt with source and target hashes, approvals, tests, exceptions, deployment time, and rollback reference.

Pin implementation guides and terminology

The page describes an artifact registry with national, domain, and custom implementation guides, plus profiles and terminology. Availability in that catalog is not deployment. Preserve each package's canonical identifier, semantic version, release and maturity status, dependencies, checksum, local overlays, load time, validation result, and consuming endpoints. If two guides constrain the same resource differently, record the precedence and unresolved conflict rather than claiming generic FHIR support.

Terminology needs the same boundary. Capture CodeSystem and ValueSet canonical URLs, versions, supplements, expansion parameters, effective times, local codes, mapping artifacts, and validation behavior. A successful lookup or resource validation under one package does not establish clinical correctness or equivalent semantics in another tenant. Corrections should preserve the earlier expansion and identify the resources, subscriptions, analytics, and downstream recipients that may be affected.

Keep endpoint success distinct from interoperability

Aidbox's official page names FHIR, SQL, GraphQL, Bulk, and Subscription endpoints. These surfaces serve different purposes and do not create identical contracts. For each exchange, retain initiating and responding actors, tenant, endpoint and operation, request identifier, resource and profile, version headers, authorization context, query parameters, response status, returned provenance, validation result, retry, and downstream acknowledgement.

Transport success is not semantic interoperability. An accepted request or delivered resource does not prove correct patient or provider identity, complete data, valid purpose of use, permitted disclosure, current terminology, receiver reconciliation, or clinical use. Multitenant authorization also requires explicit isolation tests for identities, clients, policies, compartments, data, logs, exports, and administrative actions. Product documentation is not a certification or independent security result.

Test a version migration across two tenants

Use a scenario in which one tenant remains on R4 while another begins an R5 migration, a shared implementation guide releases a new dependency, a local profile changes cardinality, a value-set expansion changes, and a subscription delivers to a downstream system still expecting the former contract. Reviewers should reproduce both environments, detect the mismatch, preserve prior artifacts, block unintended cross-tenant use, reconcile affected records, and produce promotion and rollback receipts.

Health Samurai's official page supports the attributed descriptions of Aidbox, its supported FHIR releases, artifact registry, implementation-guide range, endpoint types, terminology functions, access-control features, multitenancy, audit trails, and deployment options. It does not establish a customer's loaded artifacts, configuration, certification, conformance, data quality, identity accuracy, authorization, tenant isolation, uptime, production reach, clinical correctness, or outcome. Health systems, payers, developers, privacy, security, clinical, terminology, data-governance, and integration owners retain those decisions.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Health Interoperability Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.