Decide a data flow
Use this page after the directional table and linked workflow detail have identified the candidate legislation, regulations, standards, confidentiality rules, guidance and other controls. This is the applicability and stop/go gate for one materially distinct flow; a candidate listing is not a finding that an instrument applies.
For the board-level answer, begin with the Executive summary. Then choose Information sharing out of primary healthcare or Information sharing into primary healthcare, open the linked workflow detail and return here with its candidate instruments. Do this before choosing a dataset, API, shared-care platform or contract.
Preserve the selected flow
Record the context carried forward from the directional and workflow pages:
| Context | Required entry |
|---|---|
| Jurisdiction | England, Scotland, Wales, Northern Ireland or a named cross-border combination; identify which organisation and processing activity bring each jurisdiction into scope. |
| Direction | Into PHC, out of PHC, or two separately assessed directional legs. |
| Workflow | The linked workflow family and its exact operational use case. |
| Message leg or event | The discrete request, response, notification, retrieval, disclosure, acknowledgement, correction or other transfer being assessed. |
| Proposition | Complete the sentence below for this leg and purpose. |
We will share [information] from [sender] to [recipient] about [person or population] for [purpose and practical benefit].
If one sentence cannot describe the flow, or if a return message has a different purpose, parties, content or authority, split it into separate decisions before continuing.
Test every candidate instrument
For every instrument carried forward from the directional matrix or workflow detail, record an explicit applicability result. Add an instrument discovered during review rather than silently replacing the candidate set.
| Test | What to record |
|---|---|
| Identity and category | Formal title or maintained abbreviation; legislation, regulation/statutory duty, standard, confidentiality rule, guidance, contract, local control or future proposal. |
| Current status | In force/current, conditionally applicable, guidance, contractual/local, draft/future, superseded or unresolved, with the relevant date. |
| Jurisdiction and addressee | Nation, organisations, roles and systems to which the instrument is addressed. |
| Scope | Purpose, direction, workflow/message leg, data, recipient, trigger, version and date conditions. |
| Applicability result | Applies, does not apply, or unresolved; give the reason. “Listed in the Standards Directory” is not a reason by itself. |
| Effect on this flow | Duty, permission, prohibition, confidentiality route, required content/format, conformance control, assurance, guidance or no current effect. |
| Evidence | Link the exact registered primary source, maintained evidence claim and any open validation item. For a standard, retain its notice, version, scope, conformance date and applicable organisations. |
Do not treat a future proposal, service capability, contract, standard or guidance document as the missing purpose or legal/confidentiality authority. See CLM-009, CLM-010, CLM-014, CLM-020 and VAL-004.
Choose the route
| If the purpose is… | Use this route | Do not assume… |
|---|---|---|
| Care, diagnosis or treatment for an identifiable person by people genuinely involved in that care | Direct-care sharing route | that “direct care” permits the whole record or any recipient |
| Research, planning, commissioning, audit, service management or population health | Beyond-care sharing route | that NHS employment, a care platform or earlier direct-care access authorises reuse |
| A mix of care and beyond-care purposes | Make a separate decision record for each purpose | that one approval can cover all uses |
| Truly anonymous information for every recipient | Record the authority for collection and anonymisation, why re-identification is not reasonably likely, and the remaining confidentiality, contractual and security controls | that anonymisation retrospectively makes the source processing lawful, or that pseudonymised information is anonymous |
| Unclear, bundled or speculative | Stop and define the purpose before continuing | that a supplier, contract or standard can supply the missing purpose |
Five stop/go questions
- What exact purpose and benefit? Record the activity, parties, frequency, geography, data items, likely harms and consequence of not sharing.
- Can the recipient identify a person? Distinguish anonymous, pseudonymised and identifiable information, special-category health data and confidential patient information.
- Who decides and who acts? Identify each controller, joint controller and processor from the facts, not a supplier or commissioner label.
- What permits or requires this flow? Record each controller’s function, power, duty or other organisational authority, Article 6 basis, Article 9 condition where needed, any Data Protection Act Schedule 1 condition, the separate confidentiality route, and Type 1 and national data opt-out results where each is in scope.
- Which instruments and delivery controls apply? Complete the applicability schedule for current legislation, regulations, statutory duties, Information Standards Notices, technical specifications, confidentiality rules, guidance, contracts and local controls. Include clinical safety, security, access, audit, retention, correction, incident and accessibility controls.
Decision rule
Every applicable layer must pass. An unresolved candidate instrument prevents approval until it is resolved or made an explicit condition that is completed before processing. A sharing agreement documents governance but does not create legal authority. Data Security and Protection Toolkit completion supports assurance but does not prove a particular flow lawful.
Show the full stop/go sequence
flowchart TD
A["Define purpose, benefit, parties and data"] --> B{"Anonymous to the recipient?"}
B -- "Yes, robustly anonymous" --> C["Check source-processing authority, confidentiality, contract and re-identification risk"]
B -- "No or uncertain" --> D["Identify controllers/processors and legal authority"]
D --> E["Select Article 6 basis and, where needed, Article 9 condition"]
E --> F{"Individual direct care?"}
F -- "Yes" --> G["Test the confidentiality route, objections and section 251B where applicable"]
F -- "No" --> H["Find explicit confidentiality consent, legal requirement, section 251/COPI or a defensible overriding-public-interest justification"]
H --> I["Test Type 1 and national data opt-outs separately where in scope"]
G --> J["Minimise, secure, explain, audit and retain appropriately"]
I --> J
C --> J
J --> K["Test each candidate instrument and apply relevant standards and controls"]
K --> L{"Every applicable layer resolved and passed?"}
L -- "No" --> M["Stop; redesign or obtain missing authority"]
L -- "Only remediable conditions remain" --> O["Approve with conditions; name owner and completion gate"]
L -- "Yes" --> N["Approve, implement, monitor and review"]Select and record the outcome
Select exactly one outcome:
- Approve — every applicable layer passes and the evidence, owners and review controls are complete.
- Approve with conditions — only named, remediable implementation conditions remain; record each owner, due date and pre-processing or pre-release completion gate.
- Stop / redesign — authority, confidentiality, necessity, applicable mandatory requirements or controllability is missing, failed or unresolved.
Use the Minimum-to-maximum requirement model for the answer shape and Record a sharing decision for the auditable record. Preserve the jurisdiction, direction, workflow, message leg, candidate set, apply/not-apply rationale, instrument status, exact evidence, outcome, conditions, accountable owners and review triggers. Check the NHS standards applicability register and Clinical safety and security controls.
Evidence: SRC-001, SRC-005, SRC-006, SRC-007, SRC-008, SRC-009, SRC-010, SRC-012.