<!-- Derived Markdown alternate of governance.md; canonical repository sources and registered evidence retain authority. -->


# Governance and clinical responsibility

Record continuity, legal controllership, clinical responsibility and permission to access information answer different questions. A safe design makes each explicit at the level of a processing activity or care pathway. [SRC-031](https://copper-tiger.pages.dev/sources/index.md#src-031) [SRC-032](https://copper-tiger.pages.dev/sources/index.md#src-032)

Use the [NHS legal framework](https://copper-tiger.pages.dev/legal-framework/index.md) for Article 6 and Article 9, confidentiality, section 251, opt-outs, agreements and worked flow decisions. It distinguishes current law from public guidance and proposed implementation.

This detailed reference informs the wider [programme definition](https://copper-tiger.pages.dev/programme-definition/index.md) and [internal Defence architecture](https://copper-tiger.pages.dev/architecture/index.md). Apply its distinctions inside Defence and then at [national/regional interfaces](https://copper-tiger.pages.dev/national-regional-integration/index.md). It is not an exhaustive programme scope or blanket approval for any purpose.

## Legal roles and operational terms

| Term | Meaning for this model |
|---|---|
| Data subject | The person to whom the personal data relates |
| Controller | Determines why and how personal data is processed |
| Processor | Acts on behalf of a controller under its instructions, with its own applicable duties |
| Joint controllers | Jointly determine purposes and means for the relevant processing |
| Custodian | Project shorthand for operational responsibility for maintaining a record; not a replacement for a legal role |
| Information Asset Owner | An internal governance role; not evidence of ownership of the patient’s information |

The ICO defines roles by the actual processing. Sharing information does not by itself make the recipient a processor or establish joint controllership. This particular guidance remains under review following the Data (Use and Access) Act. The [legal reference](https://copper-tiger.pages.dev/legal-framework/index.md#changes-under-the-data-use-and-access-act-2025) records commenced changes and the updated lawful-basis guidance; a review notice does not mean the Act is wholly uncommenced. [SRC-031](https://copper-tiger.pages.dev/sources/index.md#src-031)

The DPHC privacy notice identifies MOD as controller. Separate clinical systems or specialties within DPHC therefore should not automatically be described as separate legal controllers. Their professional authorship and responsibilities still matter. [SRC-012](https://copper-tiger.pages.dev/sources/index.md#src-012)

The [record roles](https://copper-tiger.pages.dev/foundations/records-and-purposes/index.md) do not determine these legal roles. The GP record is both a source record and the primary record of care (PRC). Community and hospital records retain their source roles when they contribute information. One application may support several record roles. Assess controllership for the actual processing, including any shared care view. [SRC-003](https://copper-tiger.pages.dev/sources/index.md#src-003) [SRC-004](https://copper-tiger.pages.dev/sources/index.md#src-004) [SRC-031](https://copper-tiger.pages.dev/sources/index.md#src-031)

## Access for care

For the proposed Defence shared care record, map the purpose and data flow before selecting a technical mechanism. Include retrieval and any stored copies; the word **view** does not determine the storage arrangement. Identify the appropriate data-protection basis, any additional condition for health information, and the confidentiality justification. These are related but separate considerations. NHS shared-record guidance provides a useful reference; applicability to a particular Defence arrangement needs its own assessment. [SRC-004](https://copper-tiger.pages.dev/sources/index.md#src-004) [SRC-032](https://copper-tiger.pages.dev/sources/index.md#src-032)

An access model should combine authenticated identity, relevant role, a legitimate care relationship, necessary information and an auditable purpose. It should address sensitive material, patient rights, exceptional access, correction and retention. A common controller does not make unrestricted internal access appropriate. [SRC-012](https://copper-tiger.pages.dev/sources/index.md#src-012) [SRC-032](https://copper-tiger.pages.dev/sources/index.md#src-032)

## Proposed DShCR access controls

The Defence Shared Care Record (DShCR) should make patient information available to clinical and administrative users when the relevant access conditions are met. A care relationship is normally required for clinical access, interpreted broadly for Defence services. Intended coverage across the Defence population does not give every user access to every item. [SRC-212](https://copper-tiger.pages.dev/sources/index.md#src-212)

The proposed model uses role-based access control (RBAC), informed by clinical need, seniority, role, function and population. User profiles managed through the Healthcare Provider Directory (HPD) should remain continuously configurable. The directory does not itself select or replace the mechanisms that authenticate users and enforce access decisions.

Break-glass access, audit, automated audit and alerts are requested capabilities. Break-glass conditions and review arrangements remain to be defined. The information available to administrative users, the permission matrix and policy lifecycle are also unresolved. HPD information about permanent and temporary facilities needs controlled disclosure, including location and geospatial detail.

<span id="proposed-permissions-across-military-medicine"></span>

## Proposed permissions across Defence healthcare and military medicine

The expanded scope requires explicit rules for both consulting information and sharing it with another recipient. The following matrix is a proposed design requirement across Defence healthcare, including occupational health-led military medicine. The framing does not make every clinical use an occupational assessment; record the actual purpose. [SRC-036](https://copper-tiger.pages.dev/sources/index.md#src-036) [SRC-221](https://copper-tiger.pages.dev/sources/index.md#src-221)

| Purpose | Proposed access or output | Decision to record |
|---|---|---|
| Clinical treatment | Relevant history and specialist detail for the treating team | Care relationship, necessary data and permitted actions |
| Occupational assessment | Information needed for the defined assessment | Assessor's role, assessment purpose and disclosure authority |
| Command or employer decision | Necessary conclusions, restrictions and advice | Recipient, justified content and authority for disclosure |
| Recruitment assessment | Information obtained through a separately authorised route | Purpose and service eligibility; do not inherit direct-care permissions |
| Secondary use | A separately justified dataset and processing route | Intended use, identifiability and applicable authority |

These boundaries draw on shared-record and professional confidentiality guidance. The recorded NDG advice concerns a specific proposed recruitment use of GP Connect. [SRC-032](https://copper-tiger.pages.dev/sources/index.md#src-032) [SRC-033](https://copper-tiger.pages.dev/sources/index.md#src-033) [SRC-028](https://copper-tiger.pages.dev/sources/index.md#src-028)

For each access, disclosure or action, the design should retain the actor, purpose, patient, data scope, source, time and exceptional-access justification where applicable. Visibility alone does not assign a task. [SRC-036](https://copper-tiger.pages.dev/sources/index.md#src-036) [SRC-032](https://copper-tiger.pages.dev/sources/index.md#src-032)

## The conditional duty to share

Section 251B of the Health and Social Care Act 2012 requires relevant bodies to share information where the statutory conditions are met. Disclosure must facilitate the individual’s care in England and be in their best interests. The provision includes exceptions and does not override data-protection law or common-law duties of care or confidence. Section 251C supplies the definitions and scope. [SRC-034](https://copper-tiger.pages.dev/sources/index.md#src-034) [SRC-035](https://copper-tiger.pages.dev/sources/index.md#src-035)

This is not an unconditional permission to share every record. Its application to a particular Defence activity must be assessed against those definitions and the actual service arrangement; neither automatic application nor a blanket Defence exemption is assumed.

## Clinical care and employment decisions

Defence’s clinical and employer functions must be distinguished. GMC guidance recognises dual obligations in the Armed Forces and occupational medicine. An employment report should be relevant and substantiated; routine disclosure of the entire clinical record is not the default. Disclosure may still be justified in particular circumstances, so the design must identify the applicable authority and scope. [SRC-033](https://copper-tiger.pages.dev/sources/index.md#src-033)

The National Data Guardian’s 2023–24 report records advice against a proposed MOD use of GP Connect for pre-employment fitness-to-serve assessment, despite candidate consent. That finding concerns the particular proposed purpose. It does not establish a blanket exclusion of MOD from every direct-care use. The distinction is central to the [interoperability assessment](https://copper-tiger.pages.dev/interoperability/index.md). [SRC-028](https://copper-tiger.pages.dev/sources/index.md#src-028)

## Information delivery and clinical accountability

A message arriving at a system does not prove that a clinician has reviewed it or accepted a new care responsibility. The proposed workflow should identify the accountable service, pending results, actions, review deadlines and escalation route. The [information-flow model](https://copper-tiger.pages.dev/information-flows/index.md) separates these steps. [SRC-018](https://copper-tiger.pages.dev/sources/index.md#src-018) [SRC-020](https://copper-tiger.pages.dev/sources/index.md#src-020) [SRC-021](https://copper-tiger.pages.dev/sources/index.md#src-021)

Continue with the [legal framework](https://copper-tiger.pages.dev/legal-framework/index.md) to turn these purpose and responsibility boundaries into a decision record for each flow. Then assess [GP Connect service access](https://copper-tiger.pages.dev/interoperability/index.md). For the shorter reading path, finish with [project status](https://copper-tiger.pages.dev/project/status/index.md) and its linked [validation queue](https://copper-tiger.pages.dev/validation-queue/index.md).
