Patient and carer access, requests, communications and contributions
At a glance
Patient-facing activity is not one data-sharing route. Record access, delegated or proxy access, transactions, communications and patient-generated clinical information have different purposes, authorities, safety risks and response obligations.
Return to the Out-of-PHC row or Into-PHC row.
Scope and boundaries
This family covers access to GP-held information, proxy or delegated functions, appointment/prescription transactions, online consultations and messages, and measurements, questionnaires, wearable or other patient-generated information.
First classify the function using the Five distinct data routes. An NHS App screen, notification or upload does not combine patient access, direct care, transactions, operational use and research into one purpose. CLM-026
Out of primary healthcare
For record access, PHC must apply the current contract and guidance, identity, safeguarding, serious-harm, third-party and proxy/child controls. Automatic prospective access and requested remaining/historical access are distinct. For a message or transaction, identify its purpose, content, channel, accessibility, status meaning, response route and fallback. CLM-023
Into primary healthcare
A patient or carer may submit a request, consultation, measurement, questionnaire, image or other information. PHC must show what service has accepted it, whether clinical responsibility has started, what response is promised, how provenance and uncertainty are represented and what happens if the digital route fails.
Formal proxy access is scoped, reviewable authority using the proxy’s own identity. Carer status or identity alone does not confer record access. CLM-044
How the requirement layers apply
| Layer | Workflow-specific position |
|---|---|
| Legislation | UK GDPR and DPA 2018, the Equality Act and other actor/function-specific duties may apply. Data-subject access, clinical record access and direct-care disclosure must not be conflated. |
| Regulations and contract | Apply the executed GP contract, current GMS/PMS regulations and function-specific requirements. Accessibility Regulations apply according to the organisation and service facts. |
| Standards | Candidate standards include Accessible Information, Identity and authentication, WCAG 2.2, DCB0129, DCB0160 and DSPT. DAPB4031 is a usage-data collection; the registered NHS App API is a permissioned communications interface, not universal authority. |
| Confidentiality and other controls | Apply common-law confidentiality, Caldicott, serious-harm and third-party review, proxy/delegated authority, coercion and safeguarding checks, accessibility, communication needs, provenance, response ownership, correction and non-digital fallback. |
Minimum, conditional and higher assurance
- Required floor: classify the function, person and authority; expose or accept only necessary information; meet safeguarding, accessibility, transparency, response and fallback duties.
- Conditional envelope: access and delegated functions remain limited by content, person, role, age/capacity and current authority; submitted information enters care only through an explicit service workflow.
- Higher-assurance ceiling: accessible multi-channel journeys with dependable identity, scoped delegation, clear status and response promises, provenance, human review, correction and safe escalation.
Failure states and ownership
Test proxy or child-transition errors, third-party disclosure, coercion, serious-harm review, inaccessible content, missing communication preferences, unread messages, urgent content sent through a non-urgent channel, submissions without clinical ownership, false device confidence, duplicate data and unavailable non-digital alternatives.
Evidence and open checks
Maintained evidence: SRC-047, SRC-048, SRC-050, SRC-051, SRC-054, SRC-056, SRC-057, SRC-064, SRC-068, SRC-069, SRC-070, SRC-076. Apply VAL-015–VAL-017, VAL-024 and VAL-029 as relevant.
Continue to Assess and record this workflow.