InterSystems FHIR Server 2026 Release Notes
This page contain release notes and compatibility information for all releases of InterSystems FHIR Server, starting with version 2026.3.0.
2026.9.0 Release Notes
FHIR Management now correctly displays FHIR instances when HTTPS terminates at a reverse proxy and communication between the proxy, web gateway, and IRIS for Health uses HTTP.
Previously, FHIR Management generated the base URL using only the protocol reported by the web gateway. In an HTTPS-termination configuration, this could produce an incorrect HTTP URL and prevent FHIR instances from appearing. FHIR Management now accounts for the original client protocol provided by the proxy.
Previously, non-ASCII characters in exported FHIR resources could become corrupted because UTF-8 encoding was not applied explicitly during file creation or retrieval.
Now, bulk FHIR uses UTF-8 encoding when writing NDJSON files to disk and returning them in HTTP responses, preventing the corruption of non-ASCII characters.
2026.8.0 Release Notes
Previously, when users with the SQLAnalyst role attempted to query a FHIR SQL projection table that they had not personally created, an error resulted, indicating that they lacked the necessary access privileges.
Now, users with the SQLAnalyst role can access FHIR SQL projection tables regardless of who created them.
A conditional update should create a new resource when no resource matching the specified search criteria exists in the FHIR repository. Previously, when no matching resource was found, the conditional update resulted in an error. This has been fixed, and a new resource is now created as expected.
Previously, the BFC failed to properly append _since filters to queries, resulting in unexpected response contents. Now, this has been fixed and queries using _since return the correct results.
The BFC export UI has 3 tables: In-Progress, Scheduled, and Completed. Previously, the In-Progress table included completed sessions. Now, the In-Progress table includes only in-progress running sessions.
2026.7.0 Release Notes
Previously, HS.FHIRServer.API.Data.QueryParameters CreateFromQueryString() retained empty search parameters, which caused no search results to be returned, and caused it to be reflected in the returned self link. Downstream uses such as $lastn had to guard against it.
Now, CreateFromQueryString() drops empty parameters from the search, eliminating these issues.
Previously, resources included in the results set due to _include or _revinclude were added to the end of the results set, using pagination dictated by the default page size or the count parameter.
Now it is possible to configure results so that each page includes a number (the default page size or the value of count) of match results, followed by any includes related to those direct results.
Previously, InterSystems FHIR Server did not provide a reason phrase to accompany status codes in responses, which could result in responses like "404 OK" or simply "404" instead of the expected "404 File Not Found" or some other more meaningful response. Now, FHIR Server populates the reason phrase on FHIR responses, so in configurations where the web server does not override the provided reason phrase, responses contain both a status code and a useful reason phrase.
Previously, loading the same resource multiple times could result in a lock error. This has been fixed.
Known Issues in 2026.7.0
In the OAuth client UI, if you re-click the Discover button after a previous click, an incorrect error message will display: "Failed to discover issuer endpoint".
This error message is false, and the issue is ultimately only visual: there is no impact to your ability to create OAuth clients.
2026.5.0 Release Notes
Internal algorithm improvements have resulted in faster FHIR ingestion performance.
The following URL prefixes are forbidden from FHIR Server or Bulk FHIR Coordinator endpoints: /api, /csp, /cloud, /isc, /ui
A UI check prevents users from submitting a URL with these prefixes, returning a descriptive error. The default URL will not include any of these prefixes.
Previously, when Prefer handling was not strict, the HS.FHIRServer.Service SearchNew() handled malformed include and reverse include search parameters by including a warning in the response, but allowing the query to proceed into OAuth2 authentication, resulting in an error.
Now, these malformed parameters are considered errors regardless of Prefer handling, which prevents the query from proceeding, which simplifies identification of the problem.
Previously, in a newly-created OAuth client, the TLS Configuration dropdown menu would not appear because a required resource %Admin_Secure was missing, creating a need to manually enter the a TLS Configuration option rather than selecting from the dropdown.
Now, this resource is no longer required, so the dropdown appears and the desired TLS Configuration option can be selected from the list.
Previously, clicking the "RESET" button in the FHIR Configuration UI would delete the endpoint. Now, reset functions correctly.
Previously, after deleting a FHIR Endpoint the HS_FHIRServer_Storage_Json.SearchTableVersion certain table rows were not deleted.
Now, the deletion logic has been updated to correctly delete these rows.
It is no longer possible to use the following prefixes in the URL when creating a new FHIR server from a cloud deployment of the FHIR management portal:
-
/api
-
/csp
-
/cloud
-
/isc
-
/ui
If one of these restricted prefixes is detected, the following error will be presented:
URL prefix must not be /api, /csp, /cloud, /isc, or /ui
When you construct the query URL for a POST /endpoints API call on a FHIR Server deployment to create a new FHIR server, the following URL prefixes cannot be used:
-
/api
-
/csp
-
/cloud
-
/isc
-
/ui
If one of these restricted prefixes is detected, the following error will be presented:
FHIR Endpoint setting 'url' = '<bad-url>' is invalid
FHIR Endpoint setting 'url' = '<bad-url>' is invalid
The default URL will take the following form:
/fhir/<fhir-version><discriminator>
<discriminator> is a, b, c, etc, depending on whether an endpoint with this name already exists.
When you construct the endpoint URL or the file URL for a Bulk FHIR configuration, the following URL prefixes are not permitted:
-
/api
-
/csp
-
/cloud
-
/isc
-
/ui
If either URL has one of the restricted prefixes, you will not be able to save your configuration. If the UI detects a restricted prefix, the following error will be presented:
URL prefix must not be /api, /csp, /cloud, /isc, or /ui
When you construct a POST /config API call on a FHIR Server deployment to create a Bulk FHIR Configuration, the following URL prefixes cannot be used in the fetch_config.endpoint_url or the storage_config.file_url:
-
/api
-
/csp
-
/cloud
-
/isc
-
/ui
Requests that contain any of these restricted URLs will receive a 400 Bad Request response.
Previously, the class HS.FHIRServer.Tools.ConfigEditor lacked the Audience and ResourceValidation fields, which prevented users from editing FHIR Endpoint settings from the terminal. Now, these fields have been added, and the FHIR Endpoint settings can be edited using the method ##class(HS.FHIRServer.ConsoleSetup).Setup() as expected.
Previously, FHIR searches that include both _maxresults and _sort would fail with HTTP 500 (Internal Server Error). This has been fixed, and now these queries succeed as expected.
2026.4.0 Release Notes
Previously, the BFC UI had some display issues related to the application of css rules. These have been fixed.
In addition, BFC standalone launch required user to re-authenticate, configs could not be deleted, and the user could be sent back to login after successful login in the event of timeout. These issues have all been fixed.
Previously, BFC-served endpoints authenticated by the "OAuth 2.0" auth adapter (which is the ONLY choice for the cloud environment) inappropriately required privileged IRIS users by the same name as the clients that obtained the access token.
Now, if the BFC auth adapter is "OAuth", the export role is added to the CSP application serving up the BFC endpoint.
You can now configure the FHIR Server to allow for a list of valid audience / aud values. Without this, customers are blocked from using Entra ID and Cognito as authorization servers.
A new "Inactive" setting for BFC configs effectively turns off the BFC endpoint, so it no longer responds to any requests from any clients. Incomplete/invalid configs can be saved in inactive mode.
Previously, in the FHIR server OAuth Quickstart UI, the application would add a "/" to the end of the issuer endpoint, even when the user entered a URL without one. This could result in failure to discover the issuer endpoint.
Now, this "/" is no longer added, and issuer endpoints can be discovered as expected.
Previously, when a system had a massive number of orphaned search table rows, the ##class(HS.HealthConnect.FHIRRepo.Upgrade.V4)."Upgrade-HSSYS-2"() upgrade step took too long to complete, which could result in blocking the upgrade and extending downtime. Furthermore, because the delete was a single atomic SQL statement (and therefore in a transaction), being interrupted would trigger a rollback.
This upgrade step is now async, which has corrected these issues.
Previously, it was difficult to distinguish BFC-implemented URLs from Fetching URLs.
Field name descriptions have been updated to clarify that BFC-implemented URLs must be relative routes, whereas the fetching urls must be complete URLs with fully-qualified domains.
Previously, the BFC config edit page returned a 404 when refreshing the page or navigating to the page via saved URL, because the BFC config endpoint was used as the route ID, preventing the browser from distinguishing between the app's route and the ID.
Now, the base64 encoded BFC config endpoint is used as the route ID, eliminating ambiguity and preventing this 404.
Previously, when the FHIR application was deployed and accessed via a URL with a web prefix that was DIFFERENT from the default as configured by the web server, the application content (right-hand side pane) didn't display.
This has been fixed.
Previously, in the FHIR Management Portal, the default audience displayed in the allowed audiences list was incorrect: Each endpoint's settings displayed the `base_url` for the last endpoint as the default audience.
Now, the endpoint settings show the `base_url` value for the correct endpoint.
Previously, attempts to load a package via the UI resulted in a 404.
Now the package gets imported correctly.
Known Issues in 2026.4.0
Currently, clicking the "RESET" button in the FHIR Configuration UI deletes the endpoint.
The workaround is to reset using a direct API call rather than using the UI.
The API call to use is:
-
serviceId is the service id of the FHIR server
-
namespace is the namespace
-
action should be reset
If you have already triggered accidental deletion of your endpoint, you can correct the situation by creating a new endpoint with the same name and configurations in the same namespace. If necessary, reapply FHIRSQL projections to the endpoint.
Currently, when you create a new OAuth client, the TLS Configuration dropdown menu does not appear. This means you must manually enter the built-in option "BFC_SSL" or your preferred TLS Configuration option rather than selecting from the dropdown.
2026.3.0 Release Notes
Previously, there was no mechanism for deleting a FHIR package, which complicated efforts to update to a newer FHIR package version. Now, it is possible to remove packages, which makes it possible to effectively update them.
The out-of-the-box configuration for the OAuth Client now integrates with additional known FHIR servers, most notably Epic, reducing the need for customization during implementation. Integration is achieved using utility functions, built in to clients, to wrap necessary functionality into methods that are invoked prior to the FHIR request being sent out.
The HTML5 path routing standard has been adopted for routing to all FHIR Server UIs, to avoid conflicts with OpenConnect OAuth2 authentication redirects to these UIs.
Because not all FHIR servers support the use of the _count parameter in patient $everything requests, some Bulk FHIR Patient/$export processes were taking unreasonable time to execute, eventually resulting in errors. Now, a new Bulk FHIR Configuration setting, "Paginate Resource Export," allows you to specify whether the target FHIR server supports _count, avoiding these delays and errors.
Previously, the Basic:subject reference was omitted as a valid _revinclude for MedicationKnowledge resources, causing certain API queries to return an error message. This has been fixed.
Previously, during upgrades, saving a Bulk FHIR configuration forced a metadata/capability statement refresh by reaching out to the FHIR server. During upgrades where the FHIR server resides on the same instance as the BFC, these metadata fetches would time out.
BFC configs now include an "is_inactive" toggle, which allows the following when set:
-
Saving "partial" or "draft" states of incomplete BFC configs
-
Deactivation or temporary disabling of a BFC endpoint without the need to delete the entire endpoint.
"is_inactive" will also be used during upgrades according to this algorithm:
-
Upgrade code makes the changes to configs, saves
-
If the specific error is failure to retrieve the target FHIR server's metadata endpoint, it will just ignore the error, and upgrade continues, using the current capability statement.
-
For any other error, it will toggle the "is_inactive" flag on, and save the config as inactive. It will also add an entry to the upgrade log with the name and endpoint of the BFC config that failed to save. This is the catch-all case. This ensures that BFC config upgrades cannot fail - At a minimum they will get updated and saved as inactive.
Previously, the "New" button was missing from the FHIR SQL Builder UI. This has been fixed.
Previously, searches with _include and _revinclude involving canonical references could return incomplete results. This has been fixed.
Previously, the "Download Logs" button did not perform download. This has been fixed.
Previously, issues with date-time data types caused errors when using $expand. These issues have been corrected.
Previously, if the 'meta' property was absent from exported resources, the resources would not be stored successfully in the data repository. The 'meta' property is no longer required in exported resources, and exported resources are stored as expected.