# Governance, assurance and procurement The [previous page](https://copper-tiger.pages.dev/foundations/information-and-work/index.md) separated information delivery from responsibility for action. This page adds the conditions for using information, assessing software and obtaining it. These decisions apply throughout service design; they are not steps to leave until the end. ## Start with the purpose and responsibility **Governance** establishes who may do what, for which purpose, under which controls. Begin with the actual activity, such as treating a patient or assessing fitness for work. Access appropriate for one purpose does not automatically cover another. [SRC-032](https://copper-tiger.pages.dev/sources/index.md#src-032) [SRC-033](https://copper-tiger.pages.dev/sources/index.md#src-033) **Processing** includes storing, viewing and sharing information. Under the UK General Data Protection Regulation (**UK GDPR**), processing identifiable health information requires a **lawful basis**: a legal ground for using personal data, listed in Article 6. Health information receives special protection, so an additional **condition** under Article 9 must also be met. Confidentiality adds a separate question about justified use or disclosure. Technical access must also match the person's role and the service's permitted use. The [legal framework](https://copper-tiger.pages.dev/legal-framework/index.md) explains these decisions and their limits; this introduction does not authorise a particular Defence flow. [SRC-043](https://copper-tiger.pages.dev/sources/index.md#src-043) [SRC-044](https://copper-tiger.pages.dev/sources/index.md#src-044) [SRC-046](https://copper-tiger.pages.dev/sources/index.md#src-046) [SRC-032](https://copper-tiger.pages.dev/sources/index.md#src-032) A **controller** determines why and how personal data is processed. A **processor** acts on a controller's behalf. These legal roles concern the processing activity. They differ from a clinician's responsibility for assessment, treatment or follow-up. Sharing records does not itself establish joint control, unrestricted access or an accepted clinical task. [SRC-031](https://copper-tiger.pages.dev/sources/index.md#src-031) [SRC-032](https://copper-tiger.pages.dev/sources/index.md#src-032) In the proposed model, **record custody** means operational responsibility for maintaining a record. It does not replace controllership or the clinical responsibilities described in [governance](https://copper-tiger.pages.dev/governance/index.md). ## Profiles, permissions and oversight **Proposed direction.** DShCR access should reflect clinical need, seniority, role, function and the relevant patient population. **Role-based access control (RBAC)** uses a user's assigned role to determine permitted actions. The proposed model also considers purpose and circumstances; seniority alone does not confer unrestricted access. A care relationship normally applies to clinical access, with a broad Defence interpretation still to be defined. [SRC-212](https://copper-tiger.pages.dev/sources/index.md#src-212) The model should allow clinical and administrative users to access any patient's information when the appropriate conditions are met. This is conditional availability, not permission for every user to see every entry. The information visible to administrative users remains unresolved. Continuously configurable profiles, managed through the **Healthcare Provider Directory (HPD)**, should support the access rules. Authentication, policy decisions and technical enforcement still need an implementation design. [SRC-212](https://copper-tiger.pages.dev/sources/index.md#src-212) The proposed controls include **break-glass** access for defined exceptional circumstances, **audit** of use, **automated audit** and alerts. Break-glass needs its own conditions and oversight; it is not a general bypass. The access matrix, alert rules and review responsibilities remain open. [SRC-212](https://copper-tiger.pages.dev/sources/index.md#src-212) The intended access to complete contributing clinical records through the DShCR remains subject to these controls. Permission to consult source detail does not automatically permit copying it into another system or using it for another purpose. Core clinical sharing and business continuity copies need defined content, access, correction and reconciliation rules. [SRC-220](https://copper-tiger.pages.dev/sources/index.md#src-220) HPD information also needs protection. A user may be authorised to find a service or understand its capabilities without seeing its precise location. Permanent and temporary facilities, deployed services and their relationships need appropriate disclosure and lifecycle rules. These are proposed requirements, not a settled Defence location policy. [SRC-212](https://copper-tiger.pages.dev/sources/index.md#src-212) ## Turn clinical needs into assessable requirements The [systems page](https://copper-tiger.pages.dev/foundations/systems-and-capabilities/index.md) introduced capabilities. To assess whether a product meets them, examine requirements at a more detailed level. The NHS capability model uses the following terms. [SRC-115](https://copper-tiger.pages.dev/sources/index.md#src-115) | Term | Relationship to the clinical need | |---|---| | epic (requirement) | A functional requirement within a capability. | | Acceptance criteria | The minimum testable functions used to assess an epic. | | Standard | Defined technical or operating requirements; applicability depends on the relevant service and contract. | | Assurance | Assessment against specified requirements, with a defined scope and stage. | A **MUST** epic is mandatory for capability assessment. A **MAY** epic is additional unless the applicable contract or supplementary standard requires it. Read the applicable version and contract before treating capability coverage as a complete workflow. [SRC-116](https://copper-tiger.pages.dev/sources/index.md#src-116) **Digital Services for Integrated Care (DSIC)** brings capabilities, standards, assurance and commercial routes into a wider NHS model. It is broader than any one product or framework. The **Buying Catalogue** helps buyers find solutions and examine their assessed capabilities. Baseline assurance checks an initial minimum set; full compliance requires the remaining applicable standards. Neither is permission for every intended local information use. [SRC-111](https://copper-tiger.pages.dev/sources/index.md#src-111) [SRC-115](https://copper-tiger.pages.dev/sources/index.md#src-115) Clinical-safety evidence for manufacturing a system and for deploying it addresses different responsibilities. Product assessment therefore does not complete the evidence needed for its local use. [SRC-100](https://copper-tiger.pages.dev/sources/index.md#src-100) [SRC-117](https://copper-tiger.pages.dev/sources/index.md#src-117) ## Understand what procurement can establish **Procurement** is the process of obtaining the required goods or services. A **framework** sets terms for later purchases. A **lot** groups part of its scope. A **call-off** is a contract awarded under that framework. Framework appointment, a local purchase and operational deployment are distinct events. [SRC-119](https://copper-tiger.pages.dev/sources/index.md#src-119) A product description explains the supplier's offering. A catalogue assessment records assessed capabilities. A framework's category scope identifies kinds of purchases it covers; an exact listing or contract award provides more specific evidence. These forms of evidence answer different questions about capability, assessment and purchase. [SRC-113](https://copper-tiger.pages.dev/sources/index.md#src-113) [SRC-115](https://copper-tiger.pages.dev/sources/index.md#src-115) [SRC-119](https://copper-tiger.pages.dev/sources/index.md#src-119) ## Bring the decisions together For our patient's specialist report, distinguish three decisions: - **Information use:** whether the receiving clinician may access the report for the intended care purpose. - **Clinical work:** who reviews and acts on the result, using the responsibilities explained on the previous page. - **System provision:** which functions are assessed, which services the contract covers and what local deployment must establish. A later occupational assessment or command report needs its own purpose and disclosure assessment. The fact that information was available for treatment does not settle those uses. [SRC-032](https://copper-tiger.pages.dev/sources/index.md#src-032) [SRC-033](https://copper-tiger.pages.dev/sources/index.md#src-033) These distinctions let the final page connect capability categories to record roles and clinical work. An available record, a configured profile, an assessed capability and a purchase each establish different things. Use [DSIC](https://copper-tiger.pages.dev/dsic/index.md), [governance](https://copper-tiger.pages.dev/governance/index.md) and the [legal framework](https://copper-tiger.pages.dev/legal-framework/index.md) for detailed requirements. Previous: [Information movement and clinical work](https://copper-tiger.pages.dev/foundations/information-and-work/index.md). Next: [Digital health capability landscape](https://copper-tiger.pages.dev/foundations/digital-health-landscape/index.md).