Terms and distinctions
Use this page for quick lookup when reading the architecture, information flows and governance model. For an introduction that explains the concepts and their relationships, start with the six-page Foundations section. The digital health landscape maps capability categories to record roles and clinical work.
| Term | Use in this wiki |
|---|---|
| Defence healthcare | The wider programme scope, including Armed Forces and civilian patients, clinical services, settings and care partners. The owner describes the military-medicine context as occupational health-led; this does not characterise every Defence healthcare activity. See programme terminology. 221 |
| Source record | The originating account of a service's care, with authorship and provenance. GP, intermediate/community and hospital records all have this role; it is not a claim of legal ownership. |
| Primary record of care (PRC) | NHS England’s description of the continuing GP-held record. It is both the source account of GP care and the continuing record incorporating relevant information from other services. See record roles. |
| Specialist source record | This wiki's shorthand for a service-specific account, including intermediate/community and hospital care. The GP record has this source role too, with the additional PRC role. See records and their purposes; the term does not require separate software. |
| Longitudinal record | A record that extends over time. GP, community and hospital records can all be longitudinal within their scope; duration alone does not give a record the PRC role. |
| Contiguous view | In the proposed DShCR, a connected presentation across contributing sources. Combined with longitudinal, it describes connection across services and over time; it does not guarantee gap-free coverage or one database. 220 |
| Civilian history | Relevant care received outside Defence; for Armed Forces patients, this includes care before, during and after service. Part of the continuing primary record. |
| Full GP record | The GP record transferred or continued on a change of primary-care provider; distinct from a summary or every source record held by other providers |
| GP2GP | A specific service for GP EHR transfer, not a synonym for all interoperability |
| Clinical correspondence | Referrals, letters, reports and summaries that communicate clinical questions, findings, treatment and plans between services. Relevant contributions can enter the PRC while each service retains its source account. |
| Transfer of care | A change in clinical responsibility within a pathway; also a label used in correspondence standards, requiring context |
| Shared care record / shared care view | Shared care record is the governed arrangement for shared information. A view is one access capability; it does not define the whole record, its storage or clinical responsibility. |
| Defence Shared Care Record (DShCR) | Proposed comprehensive, primarily read-only overview across multiple clinical source systems and relevant tools, alongside the continuing PRC. It should connect information across sources and time, with authorised access to complete contributing clinical records through one view. Coverage, currency and permissions qualify that objective; sources retain authorship and corrections. 212, 220 |
| Patient-facing record service / personal health record (PHR) | A service for the patient, distinct from the PRC. NHS England describes a PHR as a record the person manages and can add information to; a viewing portal does not establish those functions. Patient contribution and return flows are options to explore in Defence. 213, 212 |
| Information access | Authorised retrieval or viewing for a defined purpose; access does not by itself transfer clinical responsibility or permit amendment |
| Information sharing | Making relevant information available to an authorised recipient, through a view or an exchange; purpose and responsibility remain explicit |
| Specific needs of military medicine | Clinical and occupational needs arising from military service; each use requires its own scope and access decision, as set out in governance |
| Summary Care Record | A particular NHS summary service; not the proposed internal Defence shared care record or the full GP record |
| GP Connect | A family of services with distinct access, update and assurance scopes |
| Clinical source authority | Provenance and accountability for an originating clinical entry; distinct from legal controllership |
| Cortisone | Existing programme context; Care Hub is a potential rebranding, not a confirmed rename. COPPER TIGER is the evolving programme/problem/architecture definition that may drive it. |
| SPR | England’s proposed Single Patient Record; corresponding devolved developments require separate assessment. |
The source terms are explained and qualified in the corresponding topic pages. The project does not assume that similar names denote identical products. 004, 007, 018, 023
The revised project scope connects civilian continuity with access across Defence clinical services and specialties. It does not give every Defence user access to every record. The primary-record explanation distinguishes temporary NHS registration from authorised dual registration. 036
Clinical and administrative terms
The distinctions below support the broader reference model. A term's meaning depends on its clinical, reporting or technical context.
| Term | Meaning and boundary |
|---|---|
| Encounter | An interaction or activity involving care of the patient; in FHIR, distinguish the Encounter resource from a longer EpisodeOfCare |
| EpisodeOfCare | In FHIR R4, a provider relationship that can group encounters; not automatically an NHS consultant episode |
| Hospital provider spell | In the cited May 2024 NHS dictionary, the period from provider admission to provider discharge; use the relevant collection's current definition when reporting |
| Referral | A request to another service for assessment, advice or care; transmission and acceptance are separate states |
| Advice and guidance | A clinical advice interaction; identify whether it remains advice or leads to a referral |
| Request, result and report | The question or order, resulting observation, and interpreted account; they can have separate identifiers, statuses and responsibilities |
| Discharge | State its context: leaving a hospital encounter, ending a service's care, or leaving military service on medical grounds |
| Post-event message (PEM) | A communication following an event; the 111 GP PEM differs from a referral requiring GP action |
| Shared-care prescribing | An agreed division of prescribing and monitoring responsibilities; not a synonym for a shared care record |
Use the correspondence catalogue for referral, advice, reports and PEM distinctions, and Defence mechanisms for military documents. The FHIR and NHS reporting concepts have different definitions. 104, 105, 029
Technical terms
| Term | Meaning and boundary |
|---|---|
| PAS | Patient Administration System; a system role, not a universal NHS product. The proposed EMPI does not take on the wider registration, appointment and patient-movement functions. |
| EMPI | Enterprise Master Patient Index. In this proposal: patient matching, linkage to a persistent internal patient identifier and a shared demographic profile, including people without an NHS number. Demographic-authority resolution is required; its method is TBC. 212 |
| HPD | Healthcare Provider Directory. In this proposal: configurable user profiles, organisations, teams, services, facilities and their relationships, including permanent and temporary deployed facilities. Directory data informs access; enforcement and disclosure policy remain separate decisions. 212 |
| IntP | Integration Platform. The proposed message broker and coupled publish–subscribe service coordinates two-way exchange among the DShCR, independent clinical source systems, supporting tools and external services. Workflow, caseload and patient-flow processing may sit elsewhere. 212, 220 |
| Publish–subscribe | An exchange pattern in which publishers make events or information available to authorised subscribers. Delivery does not establish clinical review or acceptance of work. |
| Core clinical information sharing | Proposed exchange of conditions, medications, vaccinations and allergies to support the DShCR and clinical use in independent source systems, including CDSS. Source authority, provenance, currency, corrections and reconciliation need defined rules. It does not establish one central clinical store. 220 |
| CDSS | Clinical decision support systems: functions that use clinical information to support decisions, such as prompts or checks. The proposal supports CDSS within specialist source systems through core clinical information sharing. Display in the DShCR does not itself establish CDSS usability. 220 |
| Business continuity / BCP | Maintaining essential service through disruption / business continuity planning. The DShCR should support BCP; retained read access, consultation capture and later reconciliation remain options with scope and implementation to be determined. Data copies alone do not establish continuity. 212, 220 |
| EPR / EHR | Electronic Patient Record / Electronic Health Record; declare the actual clinical and organisational scope rather than inferring it from the label |
| ADT | Admission, discharge and transfer messaging; includes other patient-administration events in HL7 v2 |
| Event / state | An occurrence or change / the condition represented at a point in time; replaying events requires defined ordering and correction rules |
| HL7 v2 | A family of message standards with trigger events, segments and fields; name the implemented version and profile |
| CDA | HL7 Clinical Document Architecture; a clinical document format, not an exchange transport |
| FHIR | Fast Healthcare Interoperability Resources; resources and interaction patterns constrained by release and implementation guide |
| Profile / implementation guide | Constraints on a base specification / instructions for a defined implementation; verify versions, scope and dependencies |
| Payload / envelope | Business content / the surrounding information used to deliver or process it; distinguish both from transport |
| ITK2 / ITK3 | Different Interoperability Toolkit specifications; ITK2 is deprecated, while the cited ITK3 catalogue is active and STU3-based |
| MESH | Message Exchange for Social Care and Health; a delivery service, not a clinical content standard |
| e-RS / BaRS | NHS e-Referral Service / Booking and Referral Standard; distinct services/specifications with defined workflows |
| ACK | Acknowledgement; specify transport, commit or application meaning. It does not inherently record clinical review |
| PDS / ODS | Personal Demographics Service / Organisation Data Service; patient-demographic and organisation identity have different roles |
| Identifier / code | A reference to a particular entity / a value with a defined meaning in a code system; preserve the issuing authority or code system. Patient, clinical item, version and delivery identifiers serve distinct purposes. |
| Content fingerprint / hash | A digest of a defined representation, potentially useful for checking content change or exact duplication. It is not a patient identity, clinical equivalence test or proof of authorship. No identifier format or hash algorithm is selected. 216, 217, 218 |
| Provenance | Where content came from, who authored or changed it, and when; keep this separate from delivery metadata |
| Idempotent processing | Proposed receiver behaviour in which repeating the same operation does not create an additional unintended effect |
The exchange reference provides the sources, versions and service boundaries for these terms. ADT examples show the difference between a message identifier, patient identifier and visit identifier. The descriptions of proposed processing behaviour are project design vocabulary.
GP IT framework and assurance terms
These terms help read the Digital Primary Care Open Framework. Many predate the October 2026 notice. A procurement label, a capability requirement and a clinical record role describe different things.
Systems and requirements
| Term | Working meaning and distinction |
|---|---|
| GPIT / Digital Primary Care (DPC) | GPIT is the general-practice technology scope; DPC names the planned procurement here. Neither identifies one application or national interface. 109 |
| DSIC | Digital Services for Integrated Care: the wider capabilities, standards, assurance and commercial model. 111 |
| TIF | Tech Innovation Framework: a route for modern core GP systems, with six minimum functions. 112 |
| Foundation EPR Solutions | Lot 1: operational GP systems spanning six core capabilities. A shared-record viewer is not automatically a foundation system. 109, 115 |
| Clinical and Operational Support Solutions / Non-Foundation | Lot 2: capabilities that support or extend foundation functions. The category is not a claim that every product supplies all 27 capabilities. 109 |
| Patient Information Maintenance — GP | Capability C13: registration, patient details, the EPR, historical information and transfers. It provides specific requirements; lifelong primary-record continuity is the broader project objective. 125 |
| Capability / epic / acceptance criteria | Business need / individual functional requirement / testable minimum for that requirement. All acceptance criteria associated with an epic must pass. 116 |
| MUST / MAY epic | Mandatory / additional functionality. A MAY can become mandatory through its contracting vehicle or supplementary care standard. 116 |
| Additional Implementation Details / Supporting Information | Mandatory implementation detail / guidance. They do not have the same assurance status. 116 |
| Standard / Supplementary Care Standard | Technical or operating conditions / requirements grouped for a specific care service. 116 |
| Effective / published future version | Requirements applying at the stated effective date / a published version awaiting its effective date. Record both status and version. 125 |
| Baseline Assurance Standard (BAS) | Initial risk-based minimum assurance, followed by remaining overarching compliance within an agreed timeframe. 115 |
| Clinical Authority to Release (CATR) | The clinical release decision described in TIF assurance. It is distinct from framework appointment and local deployment. 117 |
| Digital Dictation / Medical Reports / Self-service Appointment Check-in | Specific capability names added by DSIC roadmap RM270 before this procurement. A dictation label alone does not establish ambient AI functionality. 118 |
| Migration / GP2GP / shared-record aggregation | A practice changes system / a patient record follows a registration change / information is assembled for shared use. These have different continuity and responsibility questions. 123, 007 |
Procurement and research
| Term | Working meaning and distinction |
|---|---|
| Lot | A defined portion of this procurement. The three lots describe purchase categories, not three clinical records or delivery phases. 109 |
| Framework / call-off contract | Terms for future purchases / a specific contract awarded under those terms. Admission is not guaranteed work. 119 |
| Open framework | Successive frameworks on substantially the same terms, with reopening opportunities. It does not mean continuous entry, open-source software or open access to patient data. 119 |
| UK3 / UK4 | Planned procurement notice / tender notice. This UK3 asks for no response and anticipates a later UK4 competition. 109 |
| Competitive flexible procedure | An authority-designed tendering procedure, potentially with several stages. Distinguish it from selection for a framework call-off. 120 |
| Award without further competition | A framework mechanism subject to its terms; it is distinct from statutory direct-award grounds outside that mechanism. The UK3 call-off wording needs clarification. 119, 109 |
| Central Digital Platform | The supplier registration route identified in this notice. Registration is a preparation requirement, not framework admission. 109 |
| Discovery / alpha / private beta / public beta | Problem research / testing approaches / limited invited use / broader use while improving the service. These explain the Lot 3 lifecycle without defining its final deliverables. 121, 122 |
Legal and governance terms
| Term | Meaning and boundary |
|---|---|
| Personal data / confidential patient information | Related but different concepts; identifiability, statutory context and confidentiality matter |
| Processing / disclosure | Processing includes use, storage and retrieval; disclosure is one form of processing |
| Lawful basis / special-category condition | Article 6 and Article 9 requirements; one does not replace the other |
| Confidentiality justification | The separate reason confidential information may be used or disclosed |
| Direct care / individual care | Use the definition applicable to the policy or service; a job title alone does not establish the purpose |
| Consent | Specify treatment consent, confidentiality consent or UK GDPR consent; avoid an unexplained single permission flag |
| Controller / processor / joint controllers | Roles determined by the actual processing; neither a record label nor a shared application settles them |
| Data sharing agreement / processor contract | Different instruments with different roles; an agreement does not create a missing legal authority |
| RBAC | Role-based access control. The proposed Defence model also considers clinical need, seniority, function, population and care relationship. A role alone does not settle every access condition. 212 |
| Break-glass | Exceptional access under defined conditions, with justification and review. It is a proposed capability, with its detailed Defence policy unresolved. 212 |
| DPIA | Data protection impact assessment: assessment of risks to people's rights and freedoms, distinct from clinical-risk management |
| Caldicott Guardian / DPO / CSO | Confidentiality judgement, data-protection oversight and clinical safety are distinct functions |
| Section 251 support / section 251B duty | Different statutory routes in different Acts; identify the complete provision and territorial scope |
| National data opt-out / care-related objection | Distinct decisions with different scopes; neither should become a universal record-deletion flag |
| Data portability | Distinguish the design goal of transferable history from the conditional Article 20 right |
| Pseudonymised / anonymous | Removing direct identifiers does not necessarily make information anonymous |
The legal reference explains each distinction, its sources and practical consequences. Use the current law and applicable guidance, including commenced changes under the Data (Use and Access) Act 2025.