InterSystems FHIR Services
This page tracks InterSystems FHIR Services from the official InterSystems UK healthcare product set.
Official InterSystems Positioning
InterSystems positions FHIR Services as managed FHIR infrastructure for organisations that need to access and use FHIR data without creating and operating their own FHIR computing infrastructure.
InterSystems documentation adds product-level depth: InterSystems FHIR Server is documented as a cloud SaaS FHIR repository exposed through REST APIs, and the broader FHIR documentation set includes server deployment, supported interactions/operations, profiles/packages, security, maintenance, Bulk FHIR Coordinator, FHIR SQL Builder, and OMOP transformation material.
Role in the Portfolio
FHIR Services is the managed infrastructure/service layer for FHIR data access and use. It should be analysed separately from IRIS for Health as a platform and separately from HealthShare as a connected-care suite, even where the technical foundations may overlap.
Technical Depth Pages
| Topic | Supported conclusion |
|---|---|
| InterSystems FHIR Server | Cloud SaaS FHIR repository and out-of-box FHIR server architecture with Resource Repository default storage, customization options, OAuth security, and secure connectivity patterns. |
| FHIR Packages and Profiles | FHIR packages, profiles, conformance resources, multiple packages per endpoint, CapabilityStatement discovery, and the non-automatic profile-validation boundary; profile validation is currently documented for FHIR R4. |
| Bulk FHIR Coordinator | Mediates bulk-data export requests between clients and FHIR endpoints, including IRIS for Health, Health Connect, HealthShare UCR, or compatible third-party endpoints, with credentialed cloud-FHIR interaction boundaries. |
| InterSystems OMOP | Cloud SaaS FHIR-to-OMOP transformation service with documented resource-to-table mapping scope. |
| SDA and CDA Transformation | SDA intermediary pattern and CDA/SDA/FHIR transformation evidence across Health Connect and IRIS for Health documentation. |
Cloud Service Boundary
The cloud-service evidence is now stronger than generic product positioning. InterSystems Cloud Services Portal documentation describes subscription, billing, cloud provider, region, tenant, deployment-size, high-availability, and service-level settings for cloud deployments; the UK cloud-hosted services overview describes managed-service controls including isolated VPCs, monitoring, stated SLA, availability-zone mirroring, optional replication, encryption, backups, RTO/RPO positioning, patching, scaling, and disaster recovery.
This still does not settle a named NHS customer's hosting region, tenancy, commercial terms, healthcare compliance commitments, or UK-specific assurance. Network Connect separately supports HSCN/private-network connectivity patterns for InterSystems cloud-service deployments, but HSCN connectivity is not the same thing as UK hosting or NHS supplier assurance.
Evidence Separation
FHIR Services is high-risk for over-reading because cloud-service documentation can look like deployment assurance. Keep these layers separate:
| Evidence layer | Current support | Boundary / next proof |
|---|---|---|
| Product capability | Managed FHIR infrastructure, FHIR Server cloud deployment, supported FHIR operations, packages/profiles, OAuth security, Network Connect, Bulk FHIR Coordinator, OMOP transformation, Cloud Services Portal settings, and cloud-hosted-service mechanics. | Product capability does not prove NHS profile conformance, local customer deployment, or clinical workflow safety. |
| NHS / UK FHIR profile support | FHIR package/profile and validation mechanics are documented, with profile validation currently designed for FHIR R4. | Need named NHS or UK Core package/profile configuration, CapabilityStatement evidence, validation settings, test results, and product/version scope. |
| Managed-service assurance | Cloud documentation supports generic region, tenant, high-availability, service-level, backup, monitoring, security, and disaster-recovery mechanics. | Need customer-specific UK region, tenancy, SLA, subprocessor/transfer terms, incident model, security pack, support-access model, and healthcare assurance artefacts. |
| Customer deployment | FHIR Services could support repository, bulk export, analytics, OMOP, or app-backend routes. | Need customer architecture, contract/procurement evidence, DSA/DPIA, DCB0129/DCB0160 where patient-care workflow is affected, controller/processor split, go-live/current-status evidence, and operational ownership. |
Evidence Status
Confidence is high for vendor positioning and for the technical documentation listed above. Current product and cloud-service pages add support for a managed FHIR service, cloud deployment, OAuth-based FHIR security, profile-validation boundaries, service-level settings, backups/management positioning, and secure network-connectivity patterns.
Remaining Follow-up Evidence
- Customer-specific service-level, support, tenancy, UK-region, and commercial-boundary documentation for healthcare use.
- Healthcare-specific compliance material beyond the general security and network-connection documentation already found.
- Product documentation naming UK national implementation guides or NHS-specific FHIR package support.
- Customer or procurement evidence where FHIR Services is explicitly named.
- Customer-specific assurance evidence for managed-service controls, including support-access, incident, subprocessor, transfer, DSA/DPIA, and clinical-safety boundaries where applicable.