Skip to content

Context Map

The wiki topic is InterSystems.

Current Domain

The current focus is UK InterSystems healthcare products and services using official InterSystems UK website sources plus selected InterSystems technical documentation, NHS, PRSB, customer trust, local-programme, FOI, marketplace, independent trade, and standards validation sources.

The Home navigation now includes an Executive Summary page that frames the core exam question: how Health Connect and HealthShare can mediate DMICP / CORTISONE connectivity with NHS England against DSIC compliance, and how the same pattern can extend to Wales, Scotland, and Northern Ireland through nation-specific connectivity routes. The Executive Summary includes a DUAA decision boundary, a healthcare-recording legal alignment boundary, and direct proof-table links: DUAA is an England statutory data and information-standard governance layer that sharpens named-standard supplier-role questions, not a DSIC or product compliance badge; healthcare-recording legal alignment is a general creation-and-maintenance model for recorded care, not a product, DSIC, or supplier-conformance label.

The Executive Summary Reference Architecture uses a compact Mermaid diagram with short labels. Keep detailed adapter names and proof requirements in the DSIC HealthShare Compliance Map, NHS England Digital Primary Care, Programme CORTISONE / UK Defence Healthcare, GP Connect and Spine Equivalents by Nation, and consolidated Evidence Matrix row rather than forcing long labels into the diagram.

Anchor Pages

Check these pages before and after domain work when the change affects their model:

  • docs/knowledge-base/modules/products-and-services.md: product and service taxonomy anchor.
  • docs/executive-summary.md: answer-led Home-section anchor for the DMICP / CORTISONE / DSIC / four-nation connectivity thesis.
  • docs/knowledge-base/modules/healthshare.md: HealthShare family and component-boundary anchor.
  • docs/evidence-domains/healthshare-components.md: HealthShare source/evidence domain split and connected-care component evidence-routing anchor.
  • docs/evidence-domains/standards-interoperability.md: standards, governance, supplier-role, Standards Directory, GP Connect / MESH / ITK3, Update Record, DUAA, and implementation-proof routing anchor.
  • docs/knowledge-base/modules/fhir-services.md: FHIR Services, FHIR Server, profiles/packages, Bulk FHIR Coordinator, OMOP, and SDA/CDA technical-depth anchor.
  • docs/knowledge-base/modules/standards-and-interoperability.md: standards, assurance, and interoperability framing anchor.
  • docs/knowledge-base/modules/data-use-and-access-act-2025.md: DUAA statutory data, privacy, digital identity, and England health/adult social care IT standards anchor.
  • docs/knowledge-base/modules/uk-healthcare-recording-legal-professional-position.md: UK healthcare-recording legal, professional, provider-governance, confidentiality, PECR, records-management, candour, and digital-standards assurance anchor; its legal alignment section is the general model for healthcare-record creation, maintenance, sharing, correction, retention, provenance, audit, and disposal.
  • docs/knowledge-base/modules/uk-nhs-evidence.md: UK NHS-facing InterSystems evidence anchor.
  • docs/knowledge-base/modules/nhs-england-digital-primary-care.md: DSIC, GP Connect, digital primary-care procurement, standards, migration, and HealthShare compliance-map anchor.
  • docs/knowledge-base/modules/devolved-connectivity-equivalents.md: Scotland, Wales, and Northern Ireland functional-equivalence anchor.
  • docs/source-evidence-domain-map.md: domain split and source/evidence navigation anchor.

If a new source changes one of these models, update the anchor, affected synthesis pages, sources.md, evidence-matrix.md, evidence-validation-queue.md, log.md, glossary entries, and LLM notes as needed in the same pass.

Follow-Up Discipline

Use What Next as a balanced work-selection mechanism, not as an automatic descent into the freshest unresolved thread. Unless the user asks to stay within one trail, recommendations should include one current-gap closure step, one anchor-model or synthesis step, and one breadth step that moves into an adjacent source/evidence domain. Each numbered step must be executable in the next pass; passive trigger conditions, "wait until a source appears" statements, and generic maintenance reminders should be recorded as boundaries in the summary, Evidence Validation Queue, Research Log, or affected synthesis page rather than occupying a What Next slot. Source and Evidence Domain Map, Evidence Validation Queue, and Context Map are background controls, not default recommendation text; mention them in What Next only when they contain the concrete artifact being changed or the next pass genuinely needs a recorded gate decision.

The current containment boundary is West Midlands Medicus / HealthShare, DUAA / ICO guidance, North West London ICS procurement confirmation, eConsult current architecture proof, and the Executive Summary architecture-boundary proof gap: those remain live Evidence Validation Queue items, but they should not dominate follow-up passes until a new source, FOI response, regulator publication, assurance decision, or user instruction changes the evidence state. Use the Executive Summary architecture-boundary row as the single holding item for missing DMICP / CORTISONE, Health Connect, HealthShare, NHS England, and four-nation adapter implementation artefacts; the DSIC HealthShare Compliance Map translates that boundary into the England artefacts GP Connect, MESH, ITK3, PDS, ODS/SDS, DSA/DPIA, and DCB0129/DCB0160. Standards Directory and interoperability mapping is now a first-class source/evidence domain. Choose a new breadth target only when repeated traversal across module pages, sources.md, evidence-matrix.md, and the Evidence Validation Queue is creating friction for the same class of question. The reusable standards-conformance request pattern and breadth gate are now recorded for sibling-project reuse in docs/llm-wiki/maintenance.md and docs/llm-wiki/starter-instruction.md; apply them from this context map before adding new request packs, checklists, or domain pages. The architecture position is that request packs add value when they make an active assurance claim actionable, but they overcomplicate the knowledge base when they multiply without a decision, delivery, research, or assurance use case. UK NHS examples have been reassessed and do not yet need a separate evidence-domain page because the overview plus independent pages remain navigable. The 2026-06-20 devolved-nations traversal-cost check does not justify a new page now; create one only if future passes repeatedly traverse the parent comparison, three connectivity pages, three InterSystems-by-nation pages, and canonical registers for the same cross-nation question. UK Defence remains contained as a source domain; use it only where the Executive Summary exam question requires CORTISONE/DMICP interface evidence. Programme CORTISONE now carries a compact DMICP interface-proof table for source interface, Health Connect mediation, HealthShare target role, and onward adapter artefacts; do not expand that trail without new source evidence or a specific assurance need. International PHC remains contained.

Evidence Clusters

  1. Product portfolio: each official product/service row has an independent page: IRIS for Health, FHIR Services, HealthShare, HealthShare Unified Care Record, HealthShare Clinical Viewer, Health Connect, TrakCare, TrakCare PHC International Evidence, and IntelliCare.
  2. Technical product depth: FHIR Server, FHIR packages/profiles, Bulk FHIR Coordinator, OMOP, and SDA/CDA transformation now have independent pages backed by InterSystems technical documentation; the 2026-06-18 follow-up pass added FHIR cloud deployment, R4 profile-validation, OAuth/security, Network Connect, Cloud Services Portal, cloud-hosted service, and Health Connect Cloud boundaries.
  3. HealthShare component split: HealthShare overview routes to independent or dedicated component pages for UCR, Clinical Viewer, EMPI, Provider Directory, Health Insight, Personal Community, Care Community, HealthShare AI Assistant, and Health Connect. The HealthShare Components Evidence Domain now groups component taxonomy, connected-care architecture, standards relevance, deployment-boundary, AI Assistant, and DSIC-adjacent evidence, with a component assurance snapshot separating shared-record/viewing, identity/directory, analytics, patient-facing/care-management, integration/standards, and AI-adjacent presentation claims. HealthShare 2026.1 detail is account-gated and AI Assistant has public sample artefacts but not full governance evidence. Care Community has current accessible Personal Community integration documentation for patient-contribution care-plan mechanics and a vendor-published Lincolnshire NHS care-plan signal, but it is complete for now unless Lincolnshire/customer confirmation becomes a specific requirement. The EMPI / Provider Directory identity-directory trail is parked pending direct artefacts: the wiki now has stronger PDS/ODS national-service dependency evidence and one PDS integrated-products row for Intersystems HealthConnect 2020.1, but no public proof of EMPI or Provider Directory PDS/ODS implementation. Reopen only for product/version scope, PDS FHIR onboarding, ODS/SDS mapping, matching/stewardship, directory governance, synchronisation, audit, safety ownership, or customer deployment artefacts.
  4. UK NHS positioning: EPR, connected care, interoperability, regional/national public-sector healthcare, and a dedicated cross-UK connectivity page that treats GP Connect as NHS England evidence while keeping Scotland, Wales, and Northern Ireland in their own source-backed digital-health contexts. Dedicated pages now track InterSystems in Scotland, Wales, and Northern Ireland.
  5. Standards and interoperability: FHIR, HL7 v2/v3, DICOM, IHE profiles, APIs, cloud-based data exchange, Network Connect, Cloud Services Portal, NHS England / DHSC standards-governance direction, Data (Use and Access) Act 2025 statutory context and staged commencement, ICO data-protection-provision status, a dedicated NHS Standards Directory relevance map covering FHIR/UK Core, GP Connect, MESH/ITK3, PDS/events, GP2GP/NHAIS, terminology, medicines, clinical safety, transfer-of-care, shared-record/life-stage content, imaging, and diagnostics, a GP Connect / MESH / ITK3 Standards Directory child page, a Standards and Interoperability Evidence Domain routing layer and canonical reusable standards-conformance evidence request pattern, a PRSB Standards parent page for record-content standards families plus the NHS England CISS funding/stewardship caveat, a PRSB Core Information Standard child page for HealthShare conformance with PRSB-specific assurance scope rather than a duplicate generic request table, NHS ITK accreditation claims, HL7 UK OIDs, GP Connect service/capability/architecture subpages, dedicated GP Connect capability subpages, a mirrored GP Connect Due Diligence section in the same capability order, structurally parsed NHS supplier-progress rows mapping IRIS for Health (Middleware) to Send Document (Send) v2.0.1 and HealthShare to Access Record: Structured Medications / Allergies / Immunisations / Uncategorised cells, and separate pages for product standards positioning, DUAA, NHS Standards Directory, ITK, PRSB, OID, and cross-UK connectivity evidence. Update Record remains a separate community-pharmacy write-back capability; its MESH/ITK3/FHIR messaging pattern is standards-adjacent but not proof of Send Document, Access Record, generic MESH API, or InterSystems implementation. NHS ITK is the current narrow implementation-proof slice: current product documentation and historical vendor claims are not enough without a current non-vendor certificate/register row, product/version scope, message/profile scope, assurance pack, and customer deployment artefacts. The 2026-06-20 current-source recheck found no current public NHS or standards-body InterSystems row in the rendered ITK catalogue or targeted public search; the Solution Assurance compliance catalogue excludes ITK Accreditation, so Healthshare-named rows there are not ITK proof. The ITK page now includes a focused evidence-request checklist and supplier/customer request template. The GP Connect InterSystems supplier-progress page translates NHS supplier-progress rows into product/version, validation-scope, exclusion, component-coverage, adjacent-standard, and deployment-artefact requests only when those rows are used for assurance. Health Connect, IRIS for Health, FHIR Services, HealthShare Unified Care Record, HealthShare Clinical Viewer, and HealthShare / PRSB CIS are high-risk product-map rows audited for product capability, presentation/access, AI-adjacent, or conformance facts versus NHS conformance, onboarding, programme/customer evidence, validation scope, profile support, SSO/RBAC/audit configuration, managed-service assurance, and customer deployment proof.
  6. DUAA: use Royal Assent date 19 June 2025 and staged commencement. ICO guidance now says all DUAA data-protection provisions are in force as of 19 June 2026. Treat section 121 / Schedule 15 as an England health/adult social care information-standard layer that can include IT and IT services and can apply to providers of IT, IT services, or information-processing services. Do not use DUAA as product conformance, DSIC catalogue, GP Connect assurance, PRSB conformance, or clinical-safety evidence. The maintained follow-up structures are the DUAA crosswalk on the NHS Standards Directory map, the GP Connect / MESH / ITK3 Standards Directory child page, the supplier artefact checklist and Birmingham / West Midlands worked evidence pack on the DSIC HealthShare Compliance Map, and the DUAA / ICO Guidance Tracker in the Evidence Validation Queue. ICO guidance now replaces GOV.UK factsheet-only treatment for complaints, lawful basis / recognised legitimate interests / purpose limitation, storage/access technologies, the main subject-access guide, and parts of international transfers; Right of Access in brief, SARs Q&A, research, automated decision-making/profiling, IDTA/Addendum transfer material, and enforcement/code process updates remain queued.
  7. Healthcare recording legal/professional position: use the UK healthcare-recording page as the anchor for UK GDPR, Data Protection Act 2018, PECR, Public Records Acts / archival governance, Access to Health Records Act 1990, Access to Health Records (Northern Ireland) Order 1993, Access to Medical Reports Act 1988, FOIA section 46 / personal-information boundaries, common law confidentiality, Caldicott, NHS Act 2006 section 251, Health and Social Care Act 2012 section 250, Health and Social Care (National Data Guardian) Act 2018, Health and Care Act 2022, DUAA 2025, professional record duties, provider governance, candour, devolved records-management codes, SNOMED CT, PRSB/provenance, DSA/DPIA, DCB0129/DCB0160, and deployment proof packs. Treat these as separate evidence layers. Use its legal alignment section for the general healthcare-record creation and maintenance model before translating that model into DSIC, HealthShare, Health Connect, DMICP, patient-facing, analytics, or AI deployment evidence. Use its public-records and health-record access route section to keep preservation/archive duties, living-patient SARs, deceased-record access, FOI/EIR, and medical-report access separate. Use Healthcare Record Source Layers for source-layer acronyms and shorthand labels such as GMC, NMC, HCPC, GPhC, CQC, NICE, PRSB, DSA/DPIA, DCB0129/DCB0160, provider governance, professional duties, and records-management code. Keep Evidence Matrix and Evidence Validation Queue source-ID-first; add visible source-layer links there only when a row defines a reusable route or synthesis boundary. Do not use product capability, DSIC status, or a generic "NHS Act" label as proof of legal/professional record compliance.
  8. NHS England Digital Primary Care: this is now a first-class parent section for DSIC and GP Connect together. It covers digital primary-care procurement, capability, standards, assurance, migration, Buying Catalogue, Tech Innovation, Digital Primary Care replacement-framework context, GP Connect deep-dive material, and the DSIC capability-to-standard crosswalk. The HealthShare compliance map treats HealthShare as a strong shared-care/integration component but not a proven complete DSIC GP foundation system without capability, standards, national-service, catalogue, and deployment evidence; it now has an Executive Summary alignment table separating Health Connect mediation, HealthShare shared-care roles, GP Connect/MESH/ITK3/PDS/ODS/SDS proof, supplier-specific adapters, and regional/four-nation adapter boundaries. It also carries the England implementation artefact map for GP Connect, MESH, ITK3, PDS, ODS/SDS, DSA/DPIA, and DCB0129/DCB0160 so those proof gaps stay tied to the consolidated architecture boundary rather than spreading into duplicate queue trails. Its visible proof-table labels link to the source-layer map for DSA/DPIA, Caldicott/confidentiality, records management, information standards, and clinical safety where readers need explanatory routing. Its legal alignment section translates the general healthcare-record creation and maintenance model into a DSIC/HealthShare evidence test. Its DUAA boundary is England standards-governance only: ask which named NHS information standard applies to which supplier role and component, then require DSIC, GP Connect, PRSB, clinical-safety, information-governance, and deployment proof separately.
  9. Devolved connectivity comparison: GP Connect, Spine, DSIC, and DUAA section 121 / Schedule 15 are NHS England or England-specific labels in the current evidence set. Use function-by-function comparisons for Scotland ECS/KIS/CHI/NDP/SCI/ePharmacy/MyCare.scot, Wales WGPR/WCP/WCCG/NDR/WDS/NHS Wales App, and Northern Ireland NIECR/encompass/EpicCare Link/HCN/DIS/ePharmacy. GP Connect and Spine Equivalents by Nation now carries the cross-nation legal-record alignment note, compact four-nation adapter proof table, and Health Connect / HealthShare adapter-logic table for the Executive Summary architecture question. Legal-record alignment is UK-wide as a structure, but records-management, candour, national-service, IG, safety, and deployment proof remain nation-specific; do not apply DSIC or DUAA labels outside England. The three country connectivity pages still point back to the Source and Evidence Domain Map promotion trigger before any future devolved-domain split.
  10. UK examples: each official InterSystems UK example has an independent page: North West London ICS, eConsult, North Tees and Hartlepool, West Midlands cancer registry/eMDT, MERIT, and ROH EPR. eConsult, North Tees, MERIT, and ROH now have stronger customer, FOI, trust, vendor, public-signal, or procurement evidence. The 2026-06-21 pass added North West London acute-trust Health Connect / Trust Integration Engine technical context, but still found no public ICB/customer programme, board, procurement, or contract-award proof for an ICS-level Health Connect Cloud operating model. The same pass added current eConsult / Huma Health Connect Cloud vendor evidence and Digital Front Door public signals naming InterSystems & eConsult, but still found no Huma, NHS, or customer-approved technical architecture pack for the current product-version and safety/deployment boundary. West Midlands cancer UHB/WMCA validation, post-2026 MERIT continuity, and ROH go-live/outcomes also remain unresolved. A separate UK NHS examples evidence-domain page is not currently needed because the overview and independent pages still provide sufficient routing; reassess only when traversal across examples becomes repetitive enough to obscure evidence type and source boundaries.
  11. Birmingham / West Midlands validation: the regional validation overview now routes to independent pages for Birmingham and Solihull ICS Shared Care Record, Collaborative Shared Care Record DPIAs, BCHC InterSystems contract-end privacy statement, NHS NRL InterSystems references, HL7 UK OIDs, ROH customer-side EPR pages, BSMHFT and Black Country Healthcare MERIT FOI records, and West Midlands cancer/eMDT context. The DSIC HealthShare Compliance Map now carries a current public artefact-pack status table, route-specific Medicus / HealthShare / GP Connect architecture table, and Medicus / West Midlands deployment-evidence checklist covering DSA/DPIA, DCB0129/DCB0160 absence, supplier responsibilities, GP Connect/MESH/ITK3 onboarding gaps, WMCA DSCR support, current Medicus/HealthShare integration signal, and official national Medicus GP Connect status. The Evidence Validation Queue now carries a FOI/source-target pack. The model boundary is explicit: national NHS Medicus evidence does not confirm the local West Midlands HealthShare route or artefacts.
  12. International TrakCare PHC/community-health evidence: Gateway Health has customer-executive corroboration but still needs a formal Gateway publication; Victoria has historical vendor evidence plus a contemporary Victorian Healthcare Association status signal; SSMS / El Bosque APS in Chile has historical and newer SSMS workflow evidence but still needs named live-scope validation; DHAMAN has TrakCare-specific trade/press evidence plus current official PHC/hospital network context but no current primary page naming TrakCare; Northern Territory Acacia is public-health and remote/community-care adjacent; Qatar remains historical academic evidence only and current PHCC sources found in the 2026-06-18 pass do not support a present Qatar TrakCare claim.
  13. Source/evidence domain split: sources.md and evidence-matrix.md remain canonical. source-evidence-domain-map.md, evidence-domains/nhs-england-digital-primary-care.md, evidence-domains/healthshare-components.md, and evidence-domains/standards-interoperability.md provide domain navigation for large source clusters without duplicating every row.
  14. Graphify and optional OKF export boundary: wiki-embedded 2D and 3D views use the same enhanced graph.json, with source-derived community names plus explicit Markdown links to, source-reference, MkDocs navigation, filesystem, and file-reference edges connecting document and code islands. Open Knowledge Format compatibility is a potential portability layer over the canonical wiki, not a new evidence domain or replacement for Graphify. Prefer a generated okf-out/ sidecar before any in-place OKF profile, and keep generated OKF output out of MkDocs and Graphify ingestion unless the tooling rules are intentionally changed.

Confidence

Product-positioning claims from official InterSystems product pages are high-confidence vendor claims. Technical documentation is high-confidence for documented product mechanics, not for customer deployment. Customer outcome and adoption claims from vendor success stories/news are moderate until externally validated. Birmingham / West Midlands now has stronger external validation for supplier existence, regional architecture, standards identifiers, programme scope, and some contract milestones, but current operational outcomes still require direct programme evidence.

For UK nations, GP Connect and Spine are currently NHS England evidence categories only. Scotland evidence is grounded in Scottish Government / COSLA digital-health and data-standards sources plus InterSystems Edinburgh office, Public Health Scotland TrakCare Patient Management System, NHS Shetland TrakCare ED / Ensemble, and vendor Scotland evidence. TrakCare PMS and TrakCare ED are source/local system labels for TrakCare in specific patient-management and emergency-department settings, not separate products or national services. Wales evidence is grounded in DHCW FHIR, primary-care, and all-Wales LIMS / TrakCare Lab Enterprise board/procurement evidence. Northern Ireland evidence is grounded in the narrow Caché / NHAIS licensing source plus DHCNI encompass / EpicCare Link / My Care and Department of Health / Rhapsody boundary evidence. The devolved connectivity pages compare similar national-service functions; those sources remain separate from GP Connect, Spine, or InterSystems claims unless new official evidence links them.