# An operating model for a software service **Turn the applicable duties into a reviewable record for every purpose.** This chapter is a recommended implementation method. The legal duties behind it are in [the legal framework](https://healthcare-data-management-wiki.pages.dev/legal-framework/index.md), [data lifecycle](https://healthcare-data-management-wiki.pages.dev/data-lifecycle/index.md), [confidentiality](https://healthcare-data-management-wiki.pages.dev/confidentiality/index.md) and [NHS standards](https://healthcare-data-management-wiki.pages.dev/nhs-standards/index.md). **For NHS patient information, the receiving organisation completes and publishes its DSPT assessment; the purchaser checks the assurance evidence.** Under this recommended operating model, the purchaser records the organisation's legal identity, assessment year, published status, service coverage and applicable audit findings. For direct receipt of identifiable GP recruitment records, the [proposed contract condition](https://healthcare-data-management-wiki.pages.dev/dspt/index.md#recommended-contract-condition) requires acceptable published status before the contractor receives records and continuing assurance afterwards. [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) ## Before the requester asks for records The requester receives the information; the GP practice or other provider receives the request and sends the information. Use [requester readiness](https://healthcare-data-management-wiki.pages.dev/requester-assurance/index.md) to prepare evidence before asking. This is the recommended sequence. A mandatory DPIA must be completed before the processing it covers starts. The requester must govern its processing even where the provider states no express conditions. [SRC-018](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-018), [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) Identify the responsible controller, implement safeguards and put the required role-specific agreements in place. Name who maintains the requester's evidence, who decides processing can start, and who verifies contractual conditions. The provider makes its own disclosure decision. Retain these decisions separately, with their scope and conditions. ## The minimum decision record | Decision | What the record should say | Responsible role to establish | |---|---|---| | Purpose and necessity | Intended outcome, population, required fields, rejected less intrusive alternatives | Controller’s accountable business owner | | Roles and data flows | Source, destination, administrator access, subprocessor, region, onward disclosure and output | Controller with each supplier | | Authority | Article 6 basis; Article 9 condition; DPA safeguards; confidentiality gateway; source permission | Controller, with appropriate IG/legal advice | | Risk and safeguards | DPIA trigger and outcome; security; re-identification, discrimination and misuse risks | Controller and relevant risk/security owners | | Requester readiness | Evidence-pack version, completed safeguards, unresolved actions, processing decision and provider disclosure conditions | Requester's named contact and responsible controller; provider owns its disclosure decision | | Contracts and approvals | Processor or sharing arrangements, NHS access terms, research conditions and product duties | Relevant parties, sponsor or regulated manufacturer | | NHS data assurance | Policy, statutory or contractual basis; supplier's legal entity, assessment year, published status, service coverage and applicable audit; acceptance date and submission deadlines | Supplier completes and publishes; purchaser checks contractual evidence; GP practice or other source provider retains its disclosure decision | | Individual choices | Notices, consent where used, opt-outs, objections, rights requests and complaints | Controller; processors assist under their instructions | | Retention and exit | Retention rationale, backup treatment, export, deletion evidence, holds and termination | Controller and processor | | Change and incident control | Trigger for reassessment, incident escalation, reporting responsibility and approval expiry | Named service and governance owners | These are suggested evidence artefacts. A document called a “data sharing agreement” is not a universal statutory prerequisite for every transfer; Article 28 processor terms have their own legal requirements. DPIA and DPO duties have defined triggers; the [stated recruitment flow engages a DPIA trigger](https://healthcare-data-management-wiki.pages.dev/requester-assurance/index.md#does-the-recruitment-requester-need-a-dpia). See [supplier and lifecycle duties](https://healthcare-data-management-wiki.pages.dev/data-lifecycle/index.md). ## Record and enforce the DSPT condition For the proposed GP-record condition, the commissioning organisation should include a binding DSPT clause in the service contract. The clause should require published **Standards Met** or **Standards Exceeded** status for the specified assessment period. It should identify the contractor, covered service, annual submission deadlines and any earlier contractual milestone. The purchaser's record should identify any independent statutory or system-access duty separately, using the [authority table](https://healthcare-data-management-wiki.pages.dev/dspt/index.md#what-makes-dspt-mandatory). Under the proposed condition, the contractor must provide published DSPT evidence before receiving identifiable NHS GP information. The purchaser's named acceptance owner should check the entity, year, status, service coverage and applicable audit findings, then record the result and date. The contract should define continuing evidence access, incident notification, remediation and proportionate suspension rights. A promise to submit later does not satisfy this proposed pre-receipt condition. The contractor must maintain assurance through annual submissions and any agreed earlier milestones under the proposed condition. The purchaser should record any permitted contractual exception expressly; it cannot waive a statutory duty or another organisation's access conditions. This recommended contract-management process leaves the responsible controller's processing decision and the GP practice's disclosure decision separate. ## Apply the analysis to the entire service Map production records, test datasets, backups, support tickets, telemetry, audit logs, exports, derived scores and model-training inputs. Avoid declaring an entire product compliant while leaving a secondary processing purpose unassessed. HRA’s development lifecycle illustrates why proof of concept, testing, care deployment and evaluation need separate consideration. [SRC-037](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-037) Keep clinical data out of support channels and development tools unless their use is authorised and controlled. Prefer the least identifiable information sufficient for the task. When NHS research access is offered through a secure data environment, follow its access and output controls. An environment constrains use; it does not itself supply legal permission. [SRC-071](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-071) [SRC-072](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-072) ## A sensible decision gate Record one of: **authorised within stated conditions**, **changes required**, **not permitted on the proposed basis**, or **insufficient information**. Explain the reason, evidence reviewed and decision owner. Identify the decision being made: processing, contractual acceptance or disclosure. An approval in one category does not decide the others. Avoid using “GDPR compliant” as an undifferentiated badge. Reassess when purpose, data, recipients, support locations, model use, clinical function or governing law changes. Track approval conditions, review dates, action owners and evidence that required changes were completed. Keep access, rights, incident and retention controls operating after receipt; annual DSPT renewal is one part of that work. This change record should link back to the [applicability map](https://healthcare-data-management-wiki.pages.dev/applicability/index.md) and [evidence matrix](https://healthcare-data-management-wiki.pages.dev/evidence-matrix/index.md). [SRC-099](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-099), [SRC-103](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-103)