NHS reference model and concept development
COPPER TIGER needs a reference model that connects clinical meaning, legal authority and technical behaviour. GP, community and hospital records preserve their source accounts. The GP record also carries the continuing primary record of care (PRC) role; a shared care view supports access to information across these records. Correspondence, events, identity and clinical work also need explicit treatment.
Read this after the proposed architecture. It develops the record roles into information objects and separate clinical, exchange and work states. The following information-flow pages apply those distinctions to communication and responsibility.
This expansion uses NHS England as the baseline, with material devolved differences identified. It covers concepts and implementation detail. New factual research uses public primary sources only, checked on 16 October 2026. An undocumented Defence mechanism is unknown, not presumed absent or supplied from operational recollection. Earlier project-intent records and the attributed timetable correction remain historical context.
This detailed reference informs the wider programme definition and internal Defence architecture. Apply its distinctions inside Defence and then at national/regional interfaces. It is not an exhaustive programme scope or blanket approval for any purpose.
Read the reference by layer
| Question | Reference | Detail provided |
|---|---|---|
| What do the words mean? | Terms and distinctions | Clinical, administrative, technical and legal meanings; terms that must not be treated as synonyms |
| What can be processed, shared or accessed, and why? | Legal framework and governance | Data protection, confidentiality, statutory and contractual scope; practical decision records |
| What information needs to move? | Clinical correspondence | Communication types, content standards, recipients, actions and worked examples |
| How can it move? | Exchange mechanisms | National services, formats, transports, identifiers, coding and assurance |
| What changes in patient or encounter state? | ADT and event messaging | Trigger events, fields, acknowledgements, cancellation, identity correction and reconciliation |
| What is evidenced in Defence? | Defence mechanisms | Published arrangements, local observations, future programmes and explicit unknowns |
After defining the model and its permitted uses, assess delivery through public Defence mechanisms and the GP IT framework research.
A richer clinical information model
The following is COPPER TIGER's proposed logical model, informed by the referenced standards. It is not a claim that Defence already has these components or requires a separate product for each.
| Object | What the model should preserve | What should remain separate |
|---|---|---|
| Person and identifiers | Identifier values, issuing authorities, verified matches and correction history | A person, a local patient number, a service number and an encounter identifier |
| Care relationship and encounter | Responsible service, purpose, period and relevant activity | An appointment booking, an actual encounter and a longer period of care |
| Clinical entry and result | Author, source, clinical time, status, interpretation and correction lineage | A finding, a request, a preliminary result and a final report |
| Correspondence document | Authored clinical account, recipients, requested actions and document version | The document's clinical identity and each delivery attempt |
| Administrative or clinical event | What changed, when, at which source and with which correlation identifiers | Event notification, the current record state and the complete clinical narrative |
| Clinical task | Named responsible service, acceptance, deadline, action, escalation and closure | Transport receipt, application processing and human review |
| Shared care view | Presentation with source identity, access controls and freshness information, whether retrieved or stored | Viewing information, creating or filing a clinical entry, and transferring the full GP record |
| Demographic profile | Shared patient details, linked source identifiers and visible reconciliation status | Person identity, clinical content and registration or appointment work |
| Provider profile and relationship | User, team, service, organisation and facility context that can inform access and routing | Directory information, access enforcement and permission to disclose precise location |
FHIR's EpisodeOfCare can link encounters within a provider relationship. It is not simply a synonym for an individual visit. ADT describes patient-administration events; clinical documents carry a different account of care. Those distinctions inform the model above. 104, 093, 095
The proposed Defence architecture assigns patient matching and shared demographics to an Enterprise Master Patient Index (EMPI). A Healthcare Provider Directory (HPD) maintains user and provider profiles. Wider patient administration remains in other tools. The Defence Shared Care Record (DShCR) is primarily a read-only overview; source systems retain authorship. The Integration Platform (IntP) brokers exchanges, while workflow processing may sit elsewhere. These are owner-directed capability boundaries, not an NHS-mandated component model. 212
Develop the concept through three independent states
COPPER TIGER should retain clinical state, exchange state and work state independently. Consider a hypothetical hospital discharge:
- The hospital ends the encounter and generates an administrative event.
- A clinician completes the discharge document, identifying medicine changes and outstanding investigations.
- The document travels through the selected route. The receiver reports technical receipt or processing as specified.
- The receiving service reviews the document and accepts any agreed tasks. Outstanding specialist work retains its own accountable service.
- A later correction links to the earlier document and reaches affected recipients without erasing the history.
These steps may occur at different times. Where the DShCR displays this progress, it should distinguish “encounter ended; summary awaited” from a completed handover. Exact work-state coverage remains to be confirmed. This follows the distinction between information transfer and clinical responsibility in the information-flow model. 018, 020, 021, 212
Technical choices remain conditional
A standards-compatible payload does not establish access to a national service. Each candidate route needs an intended use, supported product/version, eligible organisations and systems, and an agreed receiving workflow. The existing GP Connect assessment illustrates those constraints. 026, 027
The proposed concept should support more than one exchange pattern: a routed document, an administrative notification, a request/result pair and an authorised query. A receiving system should preserve the original meaning when it derives a common view. Where a mapping loses meaning, record that limitation and retain the source representation.
For example, a military occupational conclusion may inform a permitted employer decision while its clinical supporting material remains subject to separate access controls. A common technical platform cannot decide that boundary. Use the legal framework and the applicable professional guidance. 033
Broader research questions
These are unresolved design questions, not an active research programme or a claim that one pathway can settle the whole model. Each topic page supplies a more detailed implementation checklist. The validation queue records parked evidence gaps and their reopening conditions.
| Research area | Questions to resolve | Required evidence or output |
|---|---|---|
| Meaning and authority | Which terms have statutory, contractual, standard-specific or local meanings? Which purpose permits each access and disclosure? | A versioned glossary and purpose-specific authority record, including nation and applicable service scope |
| Information and mechanisms | Which correspondence types, events and request/result exchanges are required? Which routes and profiles support them, including correction and failure handling? | A correspondence catalogue and interface contracts with versions, identifiers, acknowledgements and clinical tasks |
| Defence application | Which mechanisms are publicly evidenced, for which organisations and dates? What can the proposed model infer, and what remains unknown? | A source-bounded mechanism map and explicit design assumptions, with public-evidence gaps in the validation queue |
Continue with clinical information flows to identify what each exchange carries and which service must act. Use the references above for the detail needed by that flow.