# Systems and capabilities The [previous page](https://copper-tiger.pages.dev/foundations/records-and-purposes/index.md) established what the records are for. This page translates those purposes into software functions. A record role, a software capability and a product are different things. A **product** packages capabilities into an offering; it does not determine their clinical purpose. ## From a record role to a software capability **EPR** means **Electronic Patient Record**; **EHR** means **Electronic Health Record**. Both terms also appear in descriptions of software. An **EPR solution** provides tools to record and manage care. State its actual scope, such as general practice or specialist services, when comparing solutions. [SRC-109](https://copper-tiger.pages.dev/sources/index.md#src-109) [SRC-112](https://copper-tiger.pages.dev/sources/index.md#src-112) A **capability** describes a need that software must support. It translates a clinical need into functions that can be specified and assessed. One product can supply several capabilities; one care pathway can depend on several products. [SRC-115](https://copper-tiger.pages.dev/sources/index.md#src-115) | Need in the patient example | Functions to look for | |---|---| | Preserve the continuing GP history | Record consultations, maintain patient information and incorporate relevant reports. | | Support the specialist's assessment | Record findings and decisions, request tests and manage results. | | Consult information from other services | Identify the patient, make relevant information available and show where it originated. | | Follow up an outstanding result | Identify the required work, its responsible team and its progress. | This is an explanatory translation of clinical needs, not a product assessment. Detailed capability requirements and the proposed workflow model appear in the [GP system references](https://copper-tiger.pages.dev/gp-it-lot-1/index.md) and [information flows](https://copper-tiger.pages.dev/information-flows/index.md). [SRC-003](https://copper-tiger.pages.dev/sources/index.md#src-003) [SRC-018](https://copper-tiger.pages.dev/sources/index.md#src-018) [SRC-125](https://copper-tiger.pages.dev/sources/index.md#src-125) [SRC-127](https://copper-tiger.pages.dev/sources/index.md#src-127) ## Foundation GP EPR: the core practice functions NHS England's capability guide requires six functions for **foundation** classification: **appointments, consultations, patient information, prescribing, referrals and resources**. Resource management covers staff and other resources needed to provide care. Together, these functions support daily general practice. A foundation product may also offer additional capabilities. [SRC-115](https://copper-tiger.pages.dev/sources/index.md#src-115) This connects the software to the **primary record of care**: the record is the continuing clinical account; foundation software provides functions through which the practice maintains and uses it. The patient-information capability covers registration, the EPR, history and record transfer. The [Lot 1 reference](https://copper-tiger.pages.dev/gp-it-lot-1/index.md) holds the detailed specification and version qualifications. [SRC-125](https://copper-tiger.pages.dev/sources/index.md#src-125) **Foundation EPR Solutions** is also a category in the planned Digital Primary Care procurement. The [Lot 1 reference](https://copper-tiger.pages.dev/gp-it-lot-1/index.md) explains its scope. Classification is not evidence of a particular purchase, successful record transfer or local deployment. [SRC-109](https://copper-tiger.pages.dev/sources/index.md#src-109) ## Combine functions around the records Supporting functions can handle documents, diagnostics or tasks. They may be available within a wider solution or through connected products. The planned **Clinical and Operational Support Solutions** category includes these functions; it does not imply that each product supplies every capability. [SRC-109](https://copper-tiger.pages.dev/sources/index.md#src-109) A **shared-record platform** brings information from contributing systems into shared use. The proposed **DShCR** supplies a primarily read-only overall view, with authorised access to complete contributing clinical records through it. This connected, longitudinal presentation remains subject to source coverage, currency and permissions. The [record-purpose page](https://copper-tiger.pages.dev/foundations/records-and-purposes/index.md#the-dshcr-alongside-the-continuing-prc) explains its relationship to the PRC. [SRC-220](https://copper-tiger.pages.dev/sources/index.md#src-220) A closely coupled **Integration Platform (IntP)** brokers information exchange in both directions between the DShCR, independent clinical source systems and other tools. Workflow, caseload and patient-flow tools may process the work that this information supports. Those functions can be packaged together or supplied separately. [SRC-212](https://copper-tiger.pages.dev/sources/index.md#src-212) [SRC-220](https://copper-tiger.pages.dev/sources/index.md#src-220) These relationships explain why **one record role does not require one application**. A broad EPR may support several specialist services, while a clinical history may draw on several systems. The [next page](https://copper-tiger.pages.dev/foundations/information-and-work/index.md#brokering-information-and-processing-work) separates brokering messages from processing clinical work. [SRC-003](https://copper-tiger.pages.dev/sources/index.md#src-003) [SRC-212](https://copper-tiger.pages.dev/sources/index.md#src-212) ## Patient identity and provider directories Connected systems must identify both the patient whose information they exchange and the people or services that use it. COPPER TIGER proposes two distinct shared services. These are required functions in the proposed architecture; their software implementation remains open. [SRC-212](https://copper-tiger.pages.dev/sources/index.md#src-212) | Service | Proposed function | Relationship and boundary | |---|---|---| | **Enterprise Master Patient Index (EMPI)** | Match patient identities, link source identifiers to a persistent internal patient identifier, and provide a shared demographic profile. Include people without an NHS number. | Helps connected systems refer to the same person and use consistent demographics. Registration, appointments and patient movements remain functions of dedicated tools or other systems. | | **Healthcare Provider Directory (HPD)** | Support user profiles and describe organisations, teams, services and their relationships, including permanent and temporary healthcare facilities. | Supplies provider context for access and service use. It includes deployed and operational settings, with location information carefully controlled. It is not by itself the whole authentication or access-enforcement design. | The EMPI's shared demographic profile is a **core requirement**. Its service must resolve demographic authority and conflicting information; the rules and method remain to be determined. An internal patient identifier identifies a person. Separate identifiers are needed for clinical items, their revisions and delivery events. [SRC-212](https://copper-tiger.pages.dev/sources/index.md#src-212) A **patient administration system (PAS)** supports administrative functions such as registration, appointments and patient movements. Those functions may be distributed across several tools. In this proposal, the EMPI supplies the identity and demographic service, rather than the whole PAS. [SRC-212](https://copper-tiger.pages.dev/sources/index.md#src-212) An optional future HPD feature could help authorised users find a service and understand its capabilities without receiving its precise location. The [governance page](https://copper-tiger.pages.dev/foundations/governance-assurance-procurement/index.md#profiles-permissions-and-oversight) explains the relationship between profiles and permissions. [SRC-212](https://copper-tiger.pages.dev/sources/index.md#src-212) ## Core clinical information and decision support **Proposed direction.** Connected clinical systems should share core information, including **conditions, medications, vaccinations and allergies**, through the IntP. This would support the shared overview and clinical use within independent specialist source systems. The **EMPI** supplies patient identity and demographics; the **HPD** supplies provider identities, profiles and relationships for access and routing. These shared services do not replace clinical source records. [SRC-220](https://copper-tiger.pages.dev/sources/index.md#src-220) **Clinical decision support systems (CDSS)** use clinical information to support decisions, for example through prompts or checks. Sharing core information should support CDSS within specialist source systems, alongside those systems' own clinical detail. Merely displaying information in the DShCR does not make it usable by another system's CDSS. The required content, coding and receiving-system functions must be specified. [SRC-220](https://copper-tiger.pages.dev/sources/index.md#src-220) **Open design questions.** Define source authority, provenance, currency, corrections and reconciliation for each information type. Sharing should preserve the originating account and clinical meaning. It does not select one central clinical store or authorise automatic overwriting of local entries. The [next page](https://copper-tiger.pages.dev/foundations/information-and-work/index.md#brokering-information-and-processing-work) connects these requirements to two-way exchange. [SRC-220](https://copper-tiger.pages.dev/sources/index.md#src-220) ## Patient-facing services and capture options NHS England's published capability model describes a **Personal Health Record (PHR)** as a secure, usable online record of health, care and wellbeing, managed by the person. It allows the person to add information; professionals can also contribute. A service that only displays clinical information should be described by that narrower function rather than assumed to provide every PHR capability. [SRC-213](https://copper-tiger.pages.dev/sources/index.md#src-213) **Options to explore.** One or more patient-facing services could provide access to information and let patients add and manage their own contributions. The PHR would have a different role from the professional source records, continuing PRC and DShCR. Consultation forms are another possible capture capability, for cross-specialty needs, gaps in existing systems or outage support. They could belong to the DShCR software suite or a separate tool. Their uses and record responsibilities remain open. [SRC-212](https://copper-tiger.pages.dev/sources/index.md#src-212) Patient contribution, clinical review and incorporation into a professional record are separate functions. The next page explains their proposed [information flows and continuity options](https://copper-tiger.pages.dev/foundations/information-and-work/index.md#patient-contributions-and-continuity-options). The [digital health capability landscape](https://copper-tiger.pages.dev/foundations/digital-health-landscape/index.md) applies these concepts across clinical settings after the explanations of information flows and governance. Previous: [Records and their purposes](https://copper-tiger.pages.dev/foundations/records-and-purposes/index.md). Next: [Information movement and clinical work](https://copper-tiger.pages.dev/foundations/information-and-work/index.md).