# Applicability map **Start with the activity and data flow.** “Healthcare data” describes a subject; it does not determine every legal duty. A supplier may perform several roles across hosting, support, analytics and model training. The matrix below identifies the facts that activate each layer. Read each linked chapter before making an applicability decision. **NHS policy requires annual DSPT assurance from organisations processing NHS patient information, including purposes beyond individual care.** This covers a receiving organisation's direct receipt of records without a live NHS connection. Private ownership or funding does not remove the policy requirement. Separate standards, contracts and NHS-system access terms can also impose duties. [SRC-056](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-056), [SRC-081](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-081) **The commissioning organisation should require DSPT contractually from a recruitment contractor receiving identifiable records directly from NHS GPs.** Under the [recommended condition](https://healthcare-data-management-wiki.pages.dev/dspt/index.md#recommended-contract-condition), the contractor must publish acceptable assurance before receiving records and maintain it throughout processing. The [worked decision](https://healthcare-data-management-wiki.pages.dev/recruitment-assurance/index.md) distinguishes that recommendation from an existing statutory or contractual obligation. **Map both directions explicitly:** the requester sends the request; the provider sends the information. The requester must establish its processing responsibilities even if the provider imposes no written conditions. Use [requester readiness](https://healthcare-data-management-wiki.pages.dev/requester-assurance/index.md) alongside this matrix, then support the provider's separate disclosure decision. [SRC-098](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-098), [SRC-103](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-103) | Layer | Trigger to test | Nature of obligation | Evidence to retain | |---|---|---|---| | [UK GDPR and DPA](https://healthcare-data-management-wiki.pages.dev/legal-framework/index.md) | Personal data in territorial/material scope; health information engages Article 9 | Direct legal duties | Purpose, Article 6 basis, Article 9 condition, relevant DPA safeguards | | [Confidentiality](https://healthcare-data-management-wiki.pages.dev/confidentiality/index.md) | Information received in circumstances importing confidence | Common law plus relevant statutory gateways | Disclosure/use authority, scope and recipient restrictions | | [DUAA amendments](https://healthcare-data-management-wiki.pages.dev/duaa-2025/index.md) | The amended provision and its commencement apply | Changes to existing law; some additional provisions | Current text, operative date and transition analysis | | [DPIA and risk assessment](https://healthcare-data-management-wiki.pages.dev/requester-assurance/index.md#does-the-recruitment-requester-need-a-dpia) | Article 35 and published mandatory triggers; otherwise processing likely to result in high risk | Controller duty before processing; the stated recruitment flow engages the opportunity/special-category trigger | Applicable assessment, controller ownership, safeguards, residual-risk action and any claimed exception. [SRC-018](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-018), [SRC-100](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-100) | | [Agreements and policy documents](https://healthcare-data-management-wiki.pages.dev/requester-assurance/index.md#which-agreement-or-document-is-required) | Actual controller/processor relationship and selected special-category condition | Article 28 terms, Article 26 arrangements and APDs where required; separate-controller sharing agreements are generally good practice unless another requirement applies | Role decision, applicable executed terms, condition-specific APD and proportionate evidence. [SRC-014](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-014), [SRC-015](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-015), [SRC-002](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-002), [SRC-099](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-099) | | [DSPT: NHS data assurance](https://healthcare-data-management-wiki.pages.dev/dspt/index.md) | An organisation processes NHS patient information or accesses an NHS system | DHSC policy requires annual assurance; statutory standards, contract clauses and system-access conditions have their own scope | The receiving organisation's legal identity, assessment year, published status, service coverage and applicable audit; the purchaser's acceptance and renewal dates | | [Other NHS standards and product assurance](https://healthcare-data-management-wiki.pages.dev/nhs-standards/index.md) | Relevant information standard, digital health product, role and commissioning context | Scoped statutory standards, product assessment and contract | Applicable notice, intended use, DTAC evidence where relevant and access terms | | [Research](https://healthcare-data-management-wiki.pages.dev/confidentiality/index.md#research-approval-and-three-meanings-of-consent) | Activity is research; design and data determine approvals | Research safeguards plus conditional approval duties | Sponsor classification, approvals, protocol and conditions | | [Clinical safety](https://healthcare-data-management-wiki.pages.dev/nhs-standards/index.md) | Health IT and deployment within applicable standard scope | Scoped information standards and contractual duties | Scope rationale, manufacturer/deployer responsibilities and safety evidence | | [Medical device](https://healthcare-data-management-wiki.pages.dev/conditional-regimes/index.md) | Software’s intended medical purpose and function | Product regulation | Qualification decision and required device documentation | | [Employment or insurance](https://healthcare-data-management-wiki.pages.dev/conditional-regimes/index.md) | Defined reports, workplace processing or decisions | Purpose-specific law and professional duties | Report rights, necessity, recipient basis and discrimination assessment | | [Other digital-service rules](https://healthcare-data-management-wiki.pages.dev/conditional-regimes/index.md) | Tracking, marketing, children, regulated cyber services or cross-border reach | Separate legal or regulatory conditions | Documented trigger and appropriate controls | ## Turn the applicability map into a decision For each layer, record one of **applies**, **does not apply**, or **not yet established**, with the reason and evidence. Separately mark any **proposed contract condition**. These are recommended recording categories. An unresolved statutory route must not silently become either an exemption or an existing obligation. For DSPT, the purchaser's decision record should distinguish DHSC policy, any applicable statutory standard, existing contract or access terms, and a proposed condition. It should identify the receiving organisation, published assessment year and status, covered service, applicable audit and evidence-acceptance date. The [authority table](https://healthcare-data-management-wiki.pages.dev/dspt/index.md#what-makes-dspt-mandatory) explains the separate grounds for each requirement. ## A practical order of assessment 1. Identify the requester and sending provider, individual, fields, intended outcomes and access locations. 2. Separate each purpose. Storage, support, evaluation and product improvement may need different analysis. 3. Determine controller, joint-controller and processor roles from actual decisions, independently of who sends a document. 4. Establish the recipient's processing grounds and the provider's disclosure authority, including confidentiality. 5. Complete required DPIAs and role-specific arrangements before the relevant processing. Implement the identified safeguards. 6. For NHS patient information, the receiving organisation supplies its DSPT evidence and the purchaser checks the entity, year, status and service coverage. Research, product and other sector requirements have separate triggers. 7. Prepare evidence for the provider's disclosure decision. Record separate owners for recipient readiness, disclosure and continuing review. This sequence combines the [legal framework](https://healthcare-data-management-wiki.pages.dev/legal-framework/index.md), [confidentiality route](https://healthcare-data-management-wiki.pages.dev/confidentiality/index.md) and [lifecycle duties](https://healthcare-data-management-wiki.pages.dev/data-lifecycle/index.md). It is a review method, not a substitute for the legal tests. ## Boundaries that commonly change the answer - An external cloud host can process for direct care; an in-house research team can process for purposes beyond individual care. Purpose is decisive. [SRC-037](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-037) - Identifiable private-sector health data can engage UK GDPR even where NHS-specific assurance does not apply. See [the legal framework](https://healthcare-data-management-wiki.pages.dev/legal-framework/index.md). - Pseudonymisation is a safeguard, not an automatic exit from personal-data or CPI rules. [SRC-029](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-029) - Secondary use may include health-service management that can meet a health-purpose condition; it is not automatically consent-only. See [Article 9 conditions](https://healthcare-data-management-wiki.pages.dev/legal-framework/index.md). - Consent, a supplier contract, DTAC assessment or a security certificate cannot replace the other necessary authorisations. See [NHS standards](https://healthcare-data-management-wiki.pages.dev/nhs-standards/index.md) and [confidentiality](https://healthcare-data-management-wiki.pages.dev/confidentiality/index.md). The [validation queue](https://healthcare-data-management-wiki.pages.dev/validation-queue/index.md) retains application-specific decisions. Clarified example flows inform recommendations; no actual contract, dataset or complete service has been assessed.