Release 2606 focuses on the workflows closest to FHIR data operations: analytics, bulk export, API behavior, prior authorization, and form reliability. The common thread is control over how FHIR data is queried, exported, exposed through APIs, and handled in payer and form workflows.
In Aidbox 2606, SQLView moves into the Analytics UI, query results can be rendered as charts, $export output can be narrowed with _elements, and REST API/history behavior can be configured per resource type. The same release also publishes a performance benchmark and documents supply chain artifacts through cosign signatures and SBOMs.
Payerbox 2606 moves forward on payer interoperability and prior authorization, with newer Da Vinci CRD, DTR, and PAS support, Payer-to-Payer export updates, and a payerbox umbrella Helm chart for full-stack Kubernetes deployment.
Formbox 2606, formerly Aidbox Forms, focuses on everyday reliability: auto-save, more reliable active-field submission, locale-aware signing timestamps, and better SDCConfig support for shared and embedded forms.
Analytics Workflows Get More Connected in Aidbox
The Analytics UI now includes SQLView, a new SQL on FHIR Library profile. It appears in the unified /analytics list together with ViewDefinition and SQLQuery, so related analytics artifacts are easier to find and manage in one place.
Teams can create and edit SQLViews, resolve dependencies, inspect lineage, and use the new sql-view notebook cell. The useful change is not only another artifact type, but a more connected workflow for shaping FHIR data with SQL on FHIR.
Chart visualization also comes to the SQL Console, Notebooks, and SQL Query views. Instead of exporting results just to check a pattern, users can run a query and review the shape of the output inside Aidbox.
Bulk Export Gets More Precise
Export consumers often need a smaller, predictable subset rather than the full FHIR resource. This is common in analytics, payer exchange, and other data-sharing workflows where unnecessary fields increase volume without adding value.
The _elements parameter for $export makes that possible in 2606. Export output can be limited to selected elements, such as name or Patient.name, while the required resourceType, id, and meta fields remain in the resource.
Filtered resources are tagged as SUBSETTED, making the partial nature of the output explicit for downstream systems. The parameter is available through GET query parameters and through the POST Parameters body.
Nested paths, for example Patient.name.family, are available through the opt-in fhir.bulk-data.export.nested-elements setting. 2606 also supports system-level bulk export, extending the export options available for larger data workflows.
API Behavior and Runtime Predictability
Resource-level Storage and API configuration gives teams control over REST API and history behavior per resource type. Instead of treating the whole API surface as one global switch, an instance can expose or retain history differently for different resource types.
Caching also gets a production-focused update. The version-based cache layer improves performance and memory usage, and it fixes cases where cached data could stay stale after underlying resources changed.
Search behavior is clearer in failure cases. Unsupported search parameters return a clear error instead of an internal error, and the SearchParameter metadata cache is invalidated on update and delete so custom search parameter changes take effect immediately.
Access changes have a shorter waiting period as well. When a new role is created for a user, the JWT cache is cleared for that specific user, allowing newly granted access to apply without waiting for normal cache expiry.
For teams evaluating deployment characteristics, the public performance benchmark gives a shared baseline for scale discussions. The supply chain security overview documents signed Docker images and SBOMs, which helps platform and security teams review the artifacts they deploy.
Payerbox Updates for Prior Auth and Payer-to-Payer Exchange
For Payer-to-Payer workflows, $bulk-member-match authenticates the calling payer through UDAP B2B, with details in Authentication. $davinci-data-export also gains the payertopayer export type for Payer-to-Payer exchange.
Provider Directory work also changes in the CMS Medicare Plan Finder pipeline. Scope filters now run inside the $export query, export output is gzip-compressed, and a runnable reference implementation is available in the Aidbox examples; the MPF Pipeline docs explain the pipeline setup.
Prior Auth APIs move to newer Da Vinci versions. CRD is upgraded to Da Vinci CRD 2.1.0 and relays decision-service errors with the original HTTP status and OperationOutcome, while DTR moves to Da Vinci DTR 2.1.0.
PAS is upgraded to Da Vinci PAS STU 2.1.0, which is now the default, with STU 2.0.1 still selectable through PAS_IG_VERSION. This keeps the prior authorization APIs aligned with the newer implementation guide version while preserving a configuration path for the previous one.
Claim/$submit now writes a ClaimResponse reference extension on the submitted Claim, linking the Claim to the resulting ClaimResponse. The operation is also idempotent on Claim.identifier, so resubmitting an existing Claim returns the existing ClaimResponse instead of creating a duplicate prior authorization.
Under PAS 2.1.0, an updated prior authorization keeps a single ClaimResponse on the original Claim. Claim/$submit and Claim/$inquire return that ClaimResponse for any Claim in the update chain.
The FHIR App Portal picks up two smaller product updates. The Developer Portal can register a backend bulk data service with a client secret for client-credentials flows, in addition to a JWKS URI, and Backend Services covers that setup; the Admin Portal has a redesigned app review card.
Kubernetes deployment gets a simpler entry point through the new payerbox umbrella Helm chart. The chart deploys the full stack, including portals, Interop APIs, Prior Auth, and Aidbox.
Formbox Improves Reliability During Form Filling and Sharing
Formbox 2606 focuses on improving reliability and everyday usability.
Auto-save now preserves form data if a form is reloaded while being completed. Form submission is also more reliable for text and date/time fields, ensuring the latest entered values are submitted even if the active field has not lost focus.
Several quality-of-life improvements are included as well. The signature item now displays the signing date and time using the browser locale, and the Calculated Expression section opens the Advanced Editor by default to reduce the risk of accidental data loss.
Form sharing has also been improved with better SDCConfig support. Shared forms can now include SDCConfig, apply themes defined in it, and the embedded form builder provides more reliable SDCConfig loading through onFetch.
Legacy Cleanup and Other Aidbox Updates
MPI $match and related functionality have been removed from Aidbox. Patient matching now lives in MDMbox, which is the product path for that capability.
The legacy engine cleanup is broader than MPI. Zen validation, the Entity/Attribute framework, the legacy FHIR Terminology Repository, and the Zen-based repository, indexes, and search implementation have all been removed.
FHIR Schema validation is now the only validation mode. The BOX_FHIR_SCHEMA_VALIDATION setting has been removed and has no effect, and validation can no longer be disabled.
Metadata output is also cleaner. /fhir/metadata no longer emits non-absolute canonical URLs in CapabilityStatement.implementationGuide, and packages without a canonical URL are omitted.
One additional protocol update is included in Aidbox 2606. The Streamable HTTP MCP transport supports direct connections from modern MCP clients such as ChatGPT and Claude, but it stays here as a secondary update rather than the main release story.
Read the Full Release Notes
This post highlights the release themes most relevant for data operations, payer workflows, and form reliability. For the complete changelog, read the release notes for Aidbox 2606, Payerbox 2606, and Formbox 2606.
The linked docs include the details needed for upgrade planning and feature configuration. They are the best place to verify exact settings, operation behavior, and product-specific release notes before implementation.
