<!-- Derived Markdown alternate of foundations/digital-health-landscape.md; canonical repository sources and registered evidence retain authority. -->


# Digital health capability landscape

The preceding pages separated record roles, software functions, information flows and permission to use them. This map brings those concepts together. A **system category** groups functions; it does not require one separate application or determine a purchasing route.

## Connect the core capabilities

The following is the proposed Defence capability map. The categories can be combined in software, while their responsibilities remain distinct. Each row links to the preceding explanation. [SRC-212](https://copper-tiger.pages.dev/sources/index.md#src-212) [SRC-220](https://copper-tiger.pages.dev/sources/index.md#src-220)

| Clinical or digital need | Capability category | Relationship to other capabilities |
|---|---|---|
| Primary care and continuity | [Foundation GP EPR and practice support](https://copper-tiger.pages.dev/foundations/systems-and-capabilities/index.md#foundation-gp-epr-the-core-practice-functions) | Maintain the GP source record and its additional PRC role, including appropriate contributions from other services. |
| Hospital, community, mental health and other specialist care | [Clinical EPR, assessment and service functions](https://copper-tiger.pages.dev/foundations/records-and-purposes/index.md#primary-and-specialist-source-records) | Maintain each service's originating account; supply relevant PRC contributions and permitted DShCR detail. |
| Laboratory and imaging services | Diagnostic workflow, results and image management | Preserve diagnostic source detail and amended reports; provide findings for clinical records and follow-up. |
| Cross-service clinical overview | [Defence Shared Care Record (DShCR)](https://copper-tiger.pages.dev/foundations/records-and-purposes/index.md#the-dshcr-alongside-the-continuing-prc) | Connect information across sources and over time, with authorised access to complete contributing records through the primarily read-only view. Coverage, currency and permissions remain explicit. |
| Information exchange | [Integration Platform (IntP) and publish–subscribe](https://copper-tiger.pages.dev/foundations/information-and-work/index.md#brokering-information-and-processing-work) | Coordinate two-way exchanges among the DShCR, independent clinical source systems, processing tools and permitted external services. Brokering does not by itself own clinical work. |
| Core clinical sharing and decision support | [Shared clinical information and CDSS](https://copper-tiger.pages.dev/foundations/systems-and-capabilities/index.md#core-clinical-information-and-decision-support) | Exchange conditions, medications, vaccinations and allergies to support clinical decision support within specialist source systems. Preserve source authority and define incorporation and reconciliation rules. |
| Work coordination | [Workflow, caseload and patient-flow tools](https://copper-tiger.pages.dev/foundations/information-and-work/index.md#brokering-information-and-processing-work) | Manage work and its progress; supply relevant status to the DShCR. Delivery alone does not establish acceptance or completion. |
| Patient identity and demographics | [Enterprise Master Patient Index (EMPI)](https://copper-tiger.pages.dev/foundations/systems-and-capabilities/index.md#patient-identity-and-provider-directories) | Link patient identifiers and provide a shared demographic profile to connected systems. Keep patient administration functions distinct. |
| Registration, appointments and movements | [Patient administration functions](https://copper-tiger.pages.dev/foundations/systems-and-capabilities/index.md#patient-identity-and-provider-directories) | Use the shared patient identity while managing administrative events in dedicated tools or other systems. |
| Users, organisations, teams and services | [Healthcare Provider Directory (HPD)](https://copper-tiger.pages.dev/foundations/systems-and-capabilities/index.md#patient-identity-and-provider-directories) | Supply configurable profiles and provider relationships, including temporary facilities; protect location details. |
| Occupational health and readiness | Assessment and permitted disclosure | Use information under the relevant purpose conditions and produce appropriately limited outputs. |
| Population and service purposes | Approved data products and controlled analysis | Apply separate authority, quality and disclosure controls; clinical access is not automatic authority for reuse. |

The PRC, DShCR and source records therefore have complementary roles. The IntP connects software; the EMPI connects patient identities and supplies shared demographics; the HPD supplies provider context. These identity and directory services do not replace clinical source records. Processing tools manage work. [Permissions and oversight](https://copper-tiger.pages.dev/foundations/governance-assurance-procurement/index.md#profiles-permissions-and-oversight) govern how users apply these capabilities.

## Separate required functions from options

The proposed core includes the shared overview, two-way information exchange, configurable access, provider context, patient matching and shared demographics. Core clinical sharing should support CDSS in specialist source systems. **Open design questions** include product boundaries, retained versus retrieved content, exact permissions, clinical and demographic authority, and reconciliation rules. No single database, common authoring system or mandatory processing chain has been selected. [SRC-212](https://copper-tiger.pages.dev/sources/index.md#src-212) [SRC-220](https://copper-tiger.pages.dev/sources/index.md#src-220)

The DShCR should support **business continuity planning (BCP)**. Retained access, consultation capture and later reconciliation are related options; their scope and implementation remain open. Other options include patient-facing services, potentially Personal Health Records (PHRs); patient contributions; wider consultation-form uses; and controlled service discovery. Their relationships are introduced on the [systems page](https://copper-tiger.pages.dev/foundations/systems-and-capabilities/index.md#patient-facing-services-and-capture-options) and [information-flow page](https://copper-tiger.pages.dev/foundations/information-and-work/index.md#patient-contributions-and-continuity-options). [SRC-212](https://copper-tiger.pages.dev/sources/index.md#src-212) [SRC-220](https://copper-tiger.pages.dev/sources/index.md#src-220)

**Public evidence** supports bounded definitions and reference requirements. **Proposed direction** identifies the Defence functions sought. Neither establishes procurement, assurance or delivered capability. A framework category also does not establish permission to access a national service or safe use in a Defence setting.

Continue with [Defence context](https://copper-tiger.pages.dev/defence-context/index.md) and the [internal architecture](https://copper-tiger.pages.dev/architecture/index.md). The [DSIC reference](https://copper-tiger.pages.dev/dsic/index.md) and [planned framework reference](https://copper-tiger.pages.dev/gp-it-framework/index.md) explain assessment and purchasing structures without fixing the future route.

Previous: [Governance, assurance and procurement](https://copper-tiger.pages.dev/foundations/governance-assurance-procurement/index.md).
