InterSystems Standards Product Map

This page tracks standards-related product positioning from official InterSystems pages.

Use Standards and Interoperability Evidence Domain for proof boundaries. This page maps product capability and vendor/documentation positioning; it does not prove current conformance, assurance, onboarding, or live customer deployment unless a row explicitly cites the relevant non-vendor or customer evidence.

Product Map

Product or service	Standards or interoperability positioning	Evidence status
IRIS for Health	Positioned as a cloud-first healthcare data and application platform for FHIR-based healthcare application development and healthcare data management; current IRIS for Health documentation also includes NHS Interoperability Toolkit material in the historical accreditation context.	High for vendor positioning and selected product documentation; boundary for current NHS conformance, onboarding, deployment, and managed-service assurance
InterSystems FHIR Services	Positioned as managed FHIR infrastructure; technical documentation adds FHIR Server, packages/profiles, profile-validation boundary, security, Network Connect, Bulk FHIR Coordinator, OMOP, Cloud Services Portal deployment settings, cloud-hosted-service boundaries, and cloud-deployment depth.	High for vendor positioning and selected technical documentation; boundary for NHS profile conformance, managed-service assurance, customer tenancy, and deployment governance
Health Connect	Positioned as a healthcare integration engine supporting HL7 v2, HL7 FHIR, DICOM, IHE profiles, APIs, cloud-based data exchange, and current health standards; documentation adds Health Connect Cloud standards, Network Connect, Cloud Services Portal deployment settings, cloud-hosted-service boundaries, and SDA/CDA/FHIR transformation evidence. PDS integrated-products evidence separately lists `Intersystems HealthConnect 2020.1` for North West Anglia NHS Foundation Trust.	High for vendor positioning, selected technical documentation, and one official PDS FHIR integrated-products row; boundary for current NHS conformance beyond that row, onboarding, deployment, and managed-service assurance
HealthShare Unified Care Record	Positioned as aggregating, normalising, and deduplicating data for analytics, FHIR applications, AI use cases, and shared longitudinal-record workflows.	High for vendor positioning and shared-care-record fit; boundary for PRSB section coverage, Clinical Viewer behaviour, identity/consent/RBAC/audit configuration, DSIC foundation compliance, and customer deployment proof
HealthShare Clinical Viewer	Positioned as the clinical presentation and access layer for HealthShare / Unified Care Record information, including browser or embedded workflow access, summary-to-detail presentation, specialty configuration, and vital-sign views. AI Assistant evidence places a newer assistant capability inside Clinical Viewer and Navigation Application workflows with source traceability, configurable data profiles, RBAC, and audit tracking.	High for vendor presentation/access positioning and historical deployment clue; boundary for SSO/RBAC/audit configuration, AI governance, clinical-safety artefacts, version scope, and current customer deployment proof
HealthShare / IRIS for Health in Programme CORTISONE	CORTISONE programme vision describes an Integration Platform, EMPI, NHS interfaces, common standards, and open standards. Vendor evidence says MOD selected HealthShare and IRIS for Health; official MOD performance files name InterSystems Corporation for Programme CORTISONE IP and EMPI measures; Contracts Finder OCDS data records a FY25-30 HealthShare / IRIS for Health licence award to Intersystems Corporation.	High for supplier, named licence package, value, and term; live configuration still needs programme-delivery and technical sources
HealthShare / PRSB Core Information Standard	PRSB lists InterSystems Healthshare as Core Information Standard Version 2, Level 2 conformant, valid until 17.06.2028. Wider PRSB standards are applicable as record-content models but are not conformance evidence unless PRSB, product documentation, or customer implementation sources name the standard.	High for PRSB conformance listing; boundary for validation scope, product/component scope, local deployment, role-view, GP Connect, FHIR, HL7, DICOM, IHE, DSIC, and clinical-safety claims

Interpretation

These claims show the standards vocabulary attached to the InterSystems UK healthcare portfolio. They do not, by themselves, prove a specific supported FHIR version, profile, message type, IHE profile, DICOM workflow, deployment architecture, tenancy model, assurance status, or customer implementation state.

Use product pages for portfolio taxonomy and vendor positioning. Use product documentation, standards-body records, NHS assurance material, and customer-side implementation evidence for technical or operational claims.

Evidence Separation

Evidence type	What this page can support	What still needs another source
Vendor product positioning	Product family, stated standards vocabulary, and intended interoperability role.	Current conformance, test status, live support, or customer deployment.
Product documentation	Documented mechanics such as FHIR endpoints, transformations, profile handling, ITK material, cloud-service settings, or monitoring patterns.	A named NHS or customer implementation using those mechanics.
Standards-body or NHS register evidence	Named conformance or supplier-progress status where a product, version, capability, or row is explicitly listed.	Local deployment, operational scope, safety case, or information-governance approval.
Customer/procurement/deployment artefacts	Live use, supplier responsibility, architecture, assurance, and operational boundaries in a named setting.	Broader product-family conformance beyond that setting.

High-Risk Row Audit: Health Connect

Health Connect is the first product-map row to receive explicit evidence separation because it is easy to over-read standards vocabulary as NHS implementation proof.

Evidence layer	Current support	Boundary / next proof
Product capability	Vendor product and documentation sources support a healthcare integration-engine role, Health Connect Cloud standards support, FHIR/HL7/CDA/SDA transformation mechanics, secure network connectivity, Cloud Services Portal settings, and cloud-hosted-service positioning.	Product capability is not the same as standards-body conformance or NHS onboarding.
NHS conformance or supplier status	PDS FHIR integrated-products evidence lists `Intersystems HealthConnect 2020.1` for North West Anglia NHS Foundation Trust as application-restricted, approved 2021-08-25. No current NHS or standards-body row was found in this pass that names Health Connect as currently ITK-conformant, GP Connect-assured, MESH-onboarded, or ITK3-conformant.	Treat the PDS row as capability-specific PDS FHIR evidence only. Need a current register, supplier-progress row, certificate, onboarding artefact, or assurance record naming product/version, capability, message/profile scope, date, status, and customer deployment role for any wider claim.
Customer deployment	Public product documentation can explain how Health Connect could support integration in a deployment.	Need customer architecture, contract/procurement evidence, DSA/DPIA, DCB0129/DCB0160 where workflow affects patient care, endpoint/mailbox/certificate ownership where applicable, monitoring, incident, and go-live/current-status evidence.
Managed-service assurance	Network Connect, Health Connect Cloud, Cloud Services Portal, and cloud-hosted-service documentation support generic service mechanics.	Need customer-specific UK hosting region, tenancy, service-level, subprocessor, security, operational-responsibility, and support-access artefacts before making a deployment assurance claim.

Do not infer broad Health Connect NHS compliance from generic standards support, the 2019 GP Connect vendor news signal, Health Connect Cloud service mechanics, the PDS FHIR integrated-products row, or a Healthshare-named row in the NHS Solution Assurance compliance catalogue unless the source explicitly names the product/version, standard/capability, assurance route, deployment role, and status.

High-Risk Row Audit: IRIS for Health

IRIS for Health is the second product-map row to receive explicit evidence separation because it appears in several different proof contexts: platform positioning, current IRIS documentation, GP Connect supplier-progress material, NHS ITK historical claims, eConsult, and Programme CORTISONE. Those contexts are related but not interchangeable.

Evidence layer	Current support	Boundary / next proof
Product capability	Vendor product evidence supports IRIS for Health as a healthcare data and application platform for FHIR-based application development and healthcare data management. Current IRIS for Health documentation includes NHS ITK material in the historical accreditation context.	Product capability and documentation presence are not current independent NHS conformance or deployment proof.
NHS conformance or supplier status	Separate NHS supplier-progress evidence maps `InterSystems IRIS for Health (Middleware)` to GP Connect Send Document (Send) `v2.0.1` elsewhere in the wiki. The NHS ITK current-source recheck found no current public ITK catalogue row or certificate naming IRIS for Health.	A GP Connect supplier-progress cell is capability-specific; it does not prove product-wide GP Connect, MESH, ITK, ITK3, DSIC, PRSB, or customer deployment compliance.
Programme or customer use	eConsult and Programme CORTISONE evidence support named selection or licence-package contexts for IRIS for Health.	Supplier selection, licence award, or programme role does not expose live configuration, interface catalogue, safety case, service levels, or current operational status.
Customer deployment	IRIS for Health could be part of a middleware, application, analytics, FHIR, or platform architecture.	Need customer architecture, contract/procurement evidence, supplier responsibility matrix, DSA/DPIA, DCB0129/DCB0160 where patient-care workflow is affected, endpoint/message ownership, monitoring, incident, and go-live/current-status evidence.

Do not infer IRIS for Health NHS compliance from the product page, historical ITK documentation, a GP Connect supplier-progress cell, eConsult selection evidence, or Programme CORTISONE licence evidence unless the source explicitly names the product/version, standard/capability, assurance route, deployment role, date, and status.

High-Risk Row Audit: FHIR Services

FHIR Services is the third product-map row to receive explicit evidence separation because managed-service evidence, FHIR profile support, cloud-service settings, and customer assurance can be over-read as a complete NHS implementation claim.

Evidence layer	Current support	Boundary / next proof
Product capability	Vendor product and technical documentation support 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 is not the same as NHS profile conformance, UK Core/GP Connect implementation, or customer assurance.
Standards and profile support	Documentation supports FHIR packages/profiles and a documented profile-validation boundary, including the current FHIR R4 validation design note.	Need named NHS or UK Core package/profile configuration, CapabilityStatement evidence, validation configuration, test results, and release/version scope before claiming NHS profile support in a deployment.
Managed-service assurance	Cloud Services Portal and cloud-hosted-service material supports generic region, tenant, high-availability, service-level, backup, monitoring, security, and disaster-recovery mechanics.	Need customer-specific UK region, tenancy, SLA, support model, security pack, subprocessor/transfer terms, incident model, and healthcare assurance artefacts before using it as NHS managed-service evidence.
Customer deployment	Public product documentation can explain how 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, live status, and operational ownership.

Do not infer FHIR Services NHS compliance from FHIR support, profile/package mechanics, OAuth security, Network Connect, Cloud Services Portal settings, or cloud-hosted-service controls unless the source explicitly names the customer or product/version, standard/profile, assurance route, hosting/tenancy boundary, deployment role, date, and status.

High-Risk Row Audit: HealthShare Unified Care Record

HealthShare Unified Care Record receives explicit evidence separation because it is central to many reusable assurance questions: shared-care record, PRSB CIS relevance, Clinical Viewer presentation, identity matching, FHIR/analytics/AI enablement, DSIC adjacency, and named customer deployments. Those are related but not interchangeable proof types.

Evidence layer	Current support	Boundary / next proof
Product capability	Vendor product evidence positions Unified Care Record as aggregating, normalising, and deduplicating decentralised data into a shared longitudinal record for workflows, analytics, FHIR applications, and AI use cases.	Product positioning is not proof of a named customer deployment, full data-source catalogue, data-quality result, consent model, or operational service boundary.
Record-content conformance	PRSB CIS evidence supports InterSystems Healthshare Version 2 Level 2 conformance and is directly relevant to shared-care-record content questions.	PRSB conformance is not section-level deployment proof, every UCR field/view, every HealthShare component, or CIS Version 3 evidence without certificate/scope detail.
Presentation and access	UCR material positions Clinical Viewer as a route for users to access the longitudinal HealthShare record.	UCR is not the same claim as Clinical Viewer configuration. Need role/view templates, RBAC, SSO, audit, specialty views, embedded workflow, and current version evidence for presentation claims.
Identity and directory dependencies	EMPI and Provider Directory are plausible UCR-adjacent components, and PDS/ODS evidence defines national identity and organisation-data dependencies for England.	PDS/ODS dependency evidence is not UCR configuration proof. Need PDS FHIR onboarding, ODS/SDS mapping, matching/stewardship, local back-office process, audit, and safety ownership for the named deployment.
DSIC and national-service adjacency	UCR is relevant to shared/integrated care capability analysis and can sit beside GP Connect, Health Connect, IRIS for Health, FHIR Server, and PRSB evidence.	Relevance is not DSIC GP foundation accreditation, GP Connect assurance, MESH/ITK/ITK3 onboarding, or supplier responsibility. Need catalogue/supplier, standards, national-service, and deployment artefacts.
Customer deployment	Birmingham / West Midlands and other shared-care-record evidence can support named deployment context when customer-side, procurement, DPIA, FOI, or programme sources are present.	Need customer architecture, data-source list, identity-matching design, role/access model, DSA/DPIA, DCB0129/DCB0160 where patient-care workflow is affected, supplier RACI, go-live/current-status evidence, monitoring, incident, and support model.

Do not infer complete UCR implementation, DSIC compliance, Clinical Viewer behaviour, PRSB section coverage, or live operational status from the product page alone. Use the reusable standards-conformance request pattern on the Standards and Interoperability Evidence Domain when a UCR claim depends on a standard, certificate, component scope, adjacent standard, or deployment artefact.

High-Risk Row Audit: HealthShare Clinical Viewer

HealthShare Clinical Viewer receives explicit evidence separation because presentation, access, RBAC, SSO, AI Assistant adjacency, and customer deployment evidence can be over-read as one claim. The current source set supports a Clinical Viewer product/presentation boundary and a historical deployment clue; it does not prove a current local access-control design or clinical-safety pack.

Evidence layer	Current support	Boundary / next proof
Presentation capability	Vendor product and resource material positions Clinical Viewer as the user-facing route for longitudinal HealthShare / UCR information, including browser or embedded workflow access, summary-to-detail navigation, specialty configuration, and vital-sign graphing.	Product presentation evidence is not a named customer build, current version, licensed feature set, specialty-template catalogue, or local clinical workflow proof.
Access, RBAC, SSO, and audit	UCR material supports access through browser or embedded workflow tools. The AI Assistant launch says the assistant operates in Clinical Viewer / Navigation Application workflows with configurable data profiles, role-based access controls, and audit tracking.	Need customer or product documentation for identity provider, SSO pattern, user provisioning, role/view templates, break-glass or emergency access if applicable, audit-log retention, access-review process, and operational ownership.
Patient and organisation context	The identity-directory pass does not create a new Clinical Viewer capability claim, but it affects proof needed where viewer access depends on patient matching, registered-GP context, ODS/SDS organisation identity, or local role/view governance.	Need deployment evidence showing how the viewer receives trusted patient identity, organisation identity, role context, and audit provenance before using Clinical Viewer as access assurance.
AI Assistant and Navigation Application adjacency	Vendor launch, sample, and product-term evidence supports an AI Assistant capability adjacent to Clinical Viewer and Navigation Application workflows.	Do not treat this as proof that Clinical Viewer itself includes AI in every deployment, that AI Assistant is available in a UK customer estate, or that model choice, prompt governance, data-flow, clinical-safety, and runtime terms are resolved.
Customer deployment	The H&W ICWR DPIA says aggregated, matched data would be displayed in Clinical Viewer in a shared regional HealthShare design.	It is historical deployment-context evidence, not current live status, current component configuration, current DSA/DPIA, final contract, supplier RACI, DCB0129/DCB0160, or local go-live proof.
Clinical safety and information governance	Product and DPIA sources establish adjacent facts that can inform safety and governance questions.	Need DCB0129/DCB0160 responsibility split, clinical hazard log ownership, role-based information-access policy, DPIA/DSA references, support/incident model, and customer-approved current operating statement before using Clinical Viewer as deployment assurance.

Do not infer complete Clinical Viewer implementation, SSO/RBAC readiness, AI governance, or live operational status from the UCR product page, AI Assistant launch, sample repository, product terms, or historical DPIA. Use the reusable standards-conformance request pattern when a Clinical Viewer claim depends on a named standard, access-control assurance, safety artefact, or customer deployment pack.

High-Risk Row Audit: HealthShare / PRSB CIS

HealthShare / PRSB Core Information Standard receives explicit evidence separation because it has unusually strong standards-body support, but that strength can be over-read into broader HealthShare, GP Connect, DSIC, customer deployment, and safety/governance claims.

Evidence layer	Current support	Boundary / next proof
PRSB conformance listing	PRSB lists InterSystems Healthshare as Core Information Standard Version 2, Level 2 conformant, valid until 17.06.2028. InterSystems separately states that HealthShare 2024.1 achieved PRSB CIS Level 2 conformance.	Need certificate or validation-scope detail if relying on section-level coverage, exclusions, product build/version, current maintenance status, or transition to a later CIS release.
Product/component scope	The conformance fact is directly relevant to HealthShare shared-care-record positioning and HealthShare Unified Care Record content use.	Do not treat the listing as separate conformance proof for Clinical Viewer, EMPI, Provider Directory, Health Connect, IRIS for Health, FHIR Services, or every HealthShare module unless the evidence names that component and scope.
Adjacent interoperability claims	Vendor material says PRSB validation included platform support for GP Connect, FHIR, HL7 v2, DICOM, and IHE profiles.	Standards named alongside the PRSB claim are not themselves GP Connect assurance, MESH/ITK/ITK3 onboarding, FHIR profile conformance, DICOM workflow proof, or DSIC compliance. Each route needs its own product/version, test, register, or customer evidence.
Customer deployment	PRSB CIS relevance can guide shared-care-record implementation questions for local HealthShare deployments.	Need customer architecture, CIS section mapping, data-source scope, role/view configuration, DSA/DPIA, DCB0129/DCB0160 where care workflow is affected, RBAC/SSO/audit evidence, go-live/current-status evidence, and operational ownership.
Future standards version	Current wiki evidence tracks CIS Version 2 / 2.01 and the PRSB-listed Version 2 conformance fact.	Recheck PRSB and NHS standards routes before using CIS Version 3 or future NHS information-standard wording as current HealthShare conformance evidence.

Do not infer full HealthShare deployment compliance from the PRSB CIS listing alone. Use it as strong record-content conformance evidence, then separately prove component scope, implementation configuration, supplier responsibilities, clinical safety, information governance, and customer go-live status.

Remaining Follow-up Evidence

Current InterSystems technical documentation for remaining standards areas not covered by the FHIR Server, profiles/packages, BFC, OMOP, and SDA/CDA pages.
Customer-specific UK healthcare security, hosting-region, service-level, and compliance material for managed services.
Customer-side examples where a named standard is live in a named deployment.
Current non-vendor conformance or assurance rows where product-level standards claims are used as compliance evidence.