commvita
Connected care platform
Third-party access

Granting a third party access to a record — and extending it when care continues

A worked example following one external care worker from a time-boxed grant, through a scoped, minimum-necessary view, to automatic expiry and a governed extension — with every step landing in an immutable, intelligent audit.

Live vs demonstrated: Live — real, API-backed platform logic (wired end-to-end today) Demonstrated — representative control surface with seeded data / illustrative UI mock-up
The scenario. Rita Okafor is a domiciliary care worker at an external provider — Bluebird Community Care. She is delivering a 6-week community rehabilitation package after a patient's hip fracture, visiting daily. She needs daily, time-boxed access to ONLY the rehab-relevant part of the record — the rehab care plan, goals, exercise programme and visit log — not the full clinical record. She is a third party to the controller: access must be least-privilege, lawful for direct care, and end by itself when the 6-week episode does.

Below: how the access is granted (A), what she can and cannot see (B), and how it auto-expires and is extended (C) — each illustrated with a representative commvita screen.

A How access is granted

A third party never gets a standing key. Access is a chain of controls the controller assembles for the duration of the care episode — and no link is skipped.

1

Controller fixes the purpose & the minimum-necessary scope

The controller decides why — supporting the patient's community rehabilitation (direct care) — and how little is needed: the rehab care plan, goals, exercise programme and visit log only, never the full record (Caldicott Principle 4 / Art.5(1)(c) data minimisation).

/ig-spine · Purpose & Legal BasisUK GDPR Art.9(2)(h)
2

External provider onboarded & assured

Bluebird Community Care self-serves capacity and profile through the Provider Portal; its DSPT / DTAC assurance and Art.28 DPA are held in Supplier IG Assurance, and — where the councils/trust jointly control the data — an Art.26 joint-controller agreement is managed in the DSPA Manager. No data flows before assurance is in place.

/provider-portal/supplier-ig-assurance/dspa-managerArt.28 · Art.26 · DSPT · DTAC
3

Time-boxed grant — scope-only, with an expiry set to the episode

Rita is given a scope-only UserGroup / UserDelegation whose expires_at is set to the rehab episode — 6 weeks. A scope-only group grants org codes, never a role; her read-only role resolves only the scoped rehab fields. Because this is direct care under Art.9(2)(h), no Caldicott gate is required.

/rbac · /rbac/user-groupseffective_scope()expires_at
4

Legitimate relationship — justified per visit

Role + scope let Rita reach the patient; opening the record on each daily visit needs a care reason. Every access is justified and logged, so the record shows exactly who looked, when and why.

/legitimate-access-logFHIR R4 AuditEvent
RBAC / Groups & Delegations / Grant time-boxed access admin
Person
Rita Okafor · Bluebird Community Care external
Role
read-only (scoped)
Minimum-necessary scope
Rehab care planGoalsExercise programmeVisit log
Full clinical record excluded — not resolvable under this grant.
Lawful basis
Direct care · Art.9(2)(h) — no Caldicott gate
Grant expires
Expires 12 Aug 2026 · 6 weeks
Grant access Cancel
Representative UI — illustrative

B What she can — and cannot — see

The grant is a boundary, not a doorway. Scope caps the view to the rehab set; everything else is invisible; every view is written to the record.

Scope caps the view to the rehab set

effective_scope() resolves only the org codes and fields the grant permits. Rita sees the rehab care plan, goals, exercise programme and visit log — and can add a visit entry — but the wider record simply does not resolve for her.

The rest of the record is not resolvable

Out-of-scope sections are not hidden buttons she might press — they are never returned by the API for her token. Data minimisation is enforced by design, not by UI.

Caldicott P4 · Art.5(1)(c)

Every view is audited

Each open and each visit log is written with a care reason to the immutable access log, giving the patient and IG a complete, tamper-evident picture of who accessed what.

/legitimate-access-log
Community Nursing / Rehab record R. Okafor · read-only
Margaret Whitfield
DOB 04 Mar 1948 · 78y · Female
NHS No 485 777 3456
Rehab episode active
Rehab care plan
Post-hip-fracture · week 3 of 6
Goals
Independent stair transfer · walk 50m
Exercise programme
Sit-to-stand ×10 · heel raises ×15 · daily
Visit log
Last visit 05 Jul · 09:14 · completed
🔒Full clinical record not in scope — problems, medications, correspondence and history are not resolvable under this grant.
Log visit
Representative UI — illustrative

C Auto-expiry & extension

The important part: access ends by itself when the episode does — and if rehab continues, it is extended by a governed re-attestation, never by a note-to-self.

1

At 6 weeks the grant self-expires

effective_scope() filters the lapsed grant at authentication time — the moment the expires_at passes, the rehab scope stops resolving and Rita's access drops automatically with no manual step. The lapse is written once (lapse_recorded) to the immutable hash chain.

expires_ateffective_scope()lapse_recordedLoginAuditEvent chain
2

Requesting an extension when care continues

If physio extends the rehab, the care coordinator (or Rita) requests an extension. The controller re-attests and sets a new expires_at via PATCH /rbac/user-groups/{id}. The grant and its new expiry are written to the tamper-evident LoginAuditEvent hash chain — access can't quietly persist or silently re-elevate; it is renewed only by an explicit, recorded decision.

PATCH /rbac/user-groups/{id}re-attestLoginAuditEvent chain
Community Nursing / Rehab record R. Okafor · read-only
Access to this record expires in 3 days — 12 Aug 2026. It will lapse automatically unless the grant is extended. Request extension
Current grant
Scope-only UserGroup · read-only · rehab set Expires 12 Aug 2026
Representative UI — illustrative
RBAC / Groups & Delegations / Request extension care_coordinator
Rehab extended by physio — 4 further weeks to reach stair-transfer and walking goals.
09 Sep 2026
Rita Okafor · read-only (scoped)
Submit for approval Cancel
Approved by K. Mensah (Care Coordinator) · re-attested · new expiry 9 Sep 2026 · written to LoginAuditEvent chain. expires_at updated
Representative UI — illustrative

D Immutable — and intelligent — audit

Every grant, access, expiry and extension lands in a log that cannot be quietly rewritten and does not just sit there — it watches for the things that matter.

Immutable by construction. Every grant, view, auto-expiry and extension is written to an append-only, SHA-256 hash-chained (WORM) log that the server re-verifies on every read — a broken chain surfaces a tamper banner. There is no update or delete endpoint.

Intelligent, not passive. The audit flags out-of-hours access and out-of-area / bulk / cross-ICS anomalies (/legitimate-access-log); the Security Console adds clinical-workflow-aware anomaly detection. And if the record is opened in another setting — hospital, out-of-hours or NHS 111 direct care — a Clinical Trigger Alert sends a safety-netting notification to the registered GP practice (/ig-spine), gated on encounter/ADT corroboration, minimum-necessary, deduplicated and rate-limited, with the acknowledgement itself audited.

Login Audit / Access trail — Margaret Whitfield admin
Chain verified — SHA-256 prev_hash → row_hash re-checked on read · no breaks · append-only.
EventWhenActorFlag
Grant created · scope-only · read-only01 Jul 2026 · 10:02K. Mensahok
Record accessed · rehab set05 Jul 2026 · 09:14R. Okaforok
Record accessed · rehab set08 Jul 2026 · 08:58R. Okaforout-of-hours
⚠ Opened in acute setting · GP practice notified (cross-setting)09 Jul 2026 · 21:37ED cliniciantrigger alert
Extension requested · +4 weeks09 Aug 2026 · 14:20R. Okaforpending
Extension approved · new expires_at 09 Sep 202609 Aug 2026 · 16:05K. Mensahre-attested
Row 4: safety-netting alert to the registered GP practice, gated on ADT corroboration, dedup/rate-limited, acknowledgement audited.
Representative UI — illustrative

Where it lives in commvita

Onboard & assure Time-boxed scope Per-visit access Auto-expiry / extend Immutable + intelligent audit
Step in the journeyModuleRouteModel / APIStandard
Onboard the external providerProvider Portal/provider-portalcapacity & profile self-serviceCQC · provider assurance
Processor assurance & DPASupplier IG Assurance/supplier-ig-assuranceDSPT / DTAC · DPA registerArt.28 · DSPT 2024/25 · DTAC
Joint-controller sharingDSPA Manager/dspa-managerDSPA lifecycle · signatoriesArt.26 · NHS DSPA template
Time-boxed scope (episode-length)RBAC · Groups & Delegations/rbac · /rbac/user-groupseffective_scope() · UserGroup · UserDelegation · expires_atODS · Caldicott P4 / Art.5(1)(c)
Extension & re-attestationRBAC · Groups & DelegationsPATCH /rbac/user-groups/{id}re-attest · lapse_recordedleast-privilege renewal
Per-visit legitimate relationshipLegitimate Relationship Log/legitimate-access-logaccess log · anomaly alerts · Art.15 SARDSPT · GDPR Art.30/15
Delegated access & consentConcierge · Consent Hub/concierge · /consent-hubdelegated access records · FHIR Consent R4GDPR Art.7 · Art.15
Community rehab contextCommunity Nursing Portal/community-nursingvisit queue · interventions · caseloadNMC 2018 · NICE SC1
Immutable audit (grant/access/expiry/extend)Login Audit · IG Spine WORM/login-auditSHA-256 hash chain · GET /auth/login-auditGDPR Art.5(1)(f) · DSPT
Intelligent audit (triggers & anomalies)IG Spine · Security Console/ig-spineClinical Trigger Alert (ADT-gated) · anomaly detectionCaldicott 8 · FHIR R4 AuditEvent
UK GDPR Art.5 / 6 / 9(2)(h) / 30 · Data Protection Act 2018Caldicott 8 PrinciplesDSPT 2024/25 Art.28 processor · Art.26 joint-controllerFHIR R4 AuditEvent / ConsentNon-SaMD IG control surface
© 2026 Commvita Digital Health Solutions Ltd. All rights reserved.