Skip to content

InterSystems FHIR Server

This page tracks the source-backed technical evidence for InterSystems FHIR Server.

Supported Positioning

InterSystems documentation describes InterSystems FHIR Server as a cloud SaaS repository for storing healthcare data as FHIR resources and exposing that data through REST APIs. Current cloud-service documentation also positions it for FHIR storage, search, analytics, SMART on FHIR application back ends, and bulk-data back ends.

The broader InterSystems FHIR server architecture also supports an out-of-box server backed by the Resource Repository. That architecture can store and retrieve FHIR resources from an InterSystems database, can be customized, and can optionally route requests through an interoperability production, though the documentation says routing through a production is not required.

Technical Shape

  • Cloud-service documentation groups the FHIR Server material with release notes, FHIR concepts, supported interactions and operations, deployment, configuration, security, maintenance, profiles/packages, Bulk FHIR Coordinator, and FHIR SQL Builder.
  • Cloud Services Portal documentation describes deployment-level choices for InterSystems cloud services including cloud provider, region, tenant, deployment size, high availability, and service-level settings.
  • The Resource Repository is documented as the default storage strategy for an InterSystems FHIR server and as sufficient to install a functioning FHIR server without new backend development tasks.
  • A custom backend is possible, but it requires custom FHIR processing logic; where a product is not licensed to install the FHIR server, the FHIR Adapter for interoperability productions is the documented alternative boundary.
  • Cloud FHIR security documentation describes OAuth 2.0 resource-server configuration and access-token checks for FHIR requests. InterSystems Network Connect separately documents secure VPN or private-circuit connectivity for cloud-service deployments.

Evidence Status

Confidence is high for documented architecture, cloud-service positioning, FHIR security mechanisms, deployment-choice concepts, and secure cloud-connectivity patterns. The page does not by itself establish a named UK hosting region, customer-specific tenancy, contract service levels, information-governance arrangements, or GP Connect assurance status.

Remaining Follow-up Evidence

  • Customer-specific service-level, hosting-region, backup, monitoring, support, and tenancy documentation for UK healthcare use.
  • Healthcare compliance and information-governance material for managed FHIR service use.
  • Customer or procurement evidence where InterSystems FHIR Server is explicitly named.