Consent Architecture

Consent that travels with the data

Patient-controlled, device-level, time-bound, and auditable. Consent architecture for healthcare that actually works.

Healthcare has a consent problem. Blanket consent forms signed once and forgotten. Consent buried in T&Cs nobody reads. No way for patients to know who's accessing their data, or to withdraw it when they want to.

The result: patients don't trust data sharing, regulators are circling, and organisations carry governance risk they can't quantify.

Inference Clinical takes a different approach. Consent is granular, patient-controlled, time-bound, and enforced at the point of data capture. It travels with the data. It's auditable at every step. And patients can see and control it themselves.

Book a Consent Architecture Review See Device Data Solutions

Consent is broken. Everyone knows it.

Blanket Consent Is Meaningless

"I consent to my data being used for care and research" — signed once, never revisited, covering everything forever. It's not informed. It's not specific. It's not what regulators want. And it's not what patients expect anymore.

Consent Is Disconnected from Data

The consent form is in a filing cabinet (or a PDF). The data is in your systems. There's no link between them. When someone asks "did the patient consent to this use?" you're scrambling.

Patients Have No Visibility

Ask a patient: "Who has access to your health data right now?" They have no idea. Neither do you, probably. When they ask to see or withdraw, it's a manual nightmare.

Withdrawal Is Practically Impossible

GDPR gives patients the right to withdraw consent. But when their data is scattered across six systems, three third parties, and a research database, withdrawal becomes a compliance exercise, not a reality.

Device Data Makes It Worse

Now add wearables, home monitors, and apps. Data flowing continuously from personal devices. Consent for what, exactly? For how long? To whom? The existing consent model wasn't built for this.

Consent owned at the device level

Consent isn't a form. It's a data structure that travels with the data it governs.

Granular, Purpose-Specific Consent

Not this:

"I consent to my data being used"

This:

  • I consent to my heart rate data
  • being shared with [Named Organisation]
  • for the purpose of cardiac rehabilitation monitoring
  • for a period of 12 weeks
  • and I can withdraw at any time

Each consent is specific:

  • What data (heart rate, blood pressure, glucose, activity...)
  • Which devices (my Apple Watch, my Libre sensor...)
  • To whom (named organisation, named care team, named system)
  • For what purpose (direct care, risk assessment, research, commercial use)
  • For how long (specific duration, until withdrawn, single use)

Patient-Controlled

Patients see their consents:

A simple interface showing:

  • What consents are active
  • What data is flowing under each consent
  • Who has accessed their data
  • When each consent expires

Patients manage their consents:

  • Grant new consents (prompted by care providers or insurers)
  • Modify existing consents (change duration, change scope)
  • Withdraw consents (with immediate effect on data flow)
  • Review access logs (who looked at what, when)

This isn't a nice-to-have. It's what patients increasingly expect, what regulators increasingly require, and what differentiates trustworthy organisations from the rest.

Enforced at the Point of Data Capture

The old model:

Data is captured → (sometime later) → Consent is checked

Our model:

Consent is verified → Data capture is authorised → Data flows with consent attached

How it works:

When a device sends data to SteadyTrace:

  1. System checks: is there an active consent for this data type, from this device, to this recipient, for this purpose?
  2. If yes: data flows, tagged with the consent reference
  3. If no: data is not captured. No ambiguity.

Consent isn't retrospective governance. It's real-time access control.

Time-Bound by Default

The old model:

Consent lasts forever (or until someone remembers to review it)

Our model — every consent has an expiry:

  • Episode-based: This consent lasts for this care episode (e.g., 12-week rehab programme)
  • Duration-based: This consent lasts for 6 months, then must be renewed
  • Event-based: This consent ends when I'm discharged / when the claim is settled / when I leave the programme

Expired consents don't silently continue. Data stops flowing. Renewal is explicit.

Auditable at Every Step

Every consent records:

  • When it was granted
  • How it was granted (app, web, verbal with witness, paper form digitised)
  • What information was provided to the patient
  • Any modifications made
  • When/if it was withdrawn
  • Every data transaction authorised under it

Every data access records:

  • Which consent authorised it
  • Who accessed the data
  • When
  • For what stated purpose
  • What they did with it

The result: When a regulator, a patient, or a lawyer asks "was this data use consented?" — you have the answer in seconds, not weeks.

How it works under the hood

Consent as FHIR Resource

Consents are structured as UK Core FHIR R4 Consent resources:

▸ Linked to Patient resource (who consented)

▸ Linked to Device resource(s) (what devices are covered)

▸ Linked to Organisation resource(s) (who can access)

▸ Purpose codes aligned to NHS and regulatory taxonomies

▸ Provision periods (valid from / valid to)

▸ Status (active, rejected, inactive, withdrawn)

Key point: Consent travels with data. Every Observation, every reading, every data point carries a reference to the Consent that authorised its collection and sharing.

Consent Enforcement Layer

SteadyTrace includes a consent enforcement engine:

▸ Real-time consent checking at data ingestion

▸ Real-time consent checking at data access

▸ Automatic expiry enforcement

▸ Withdrawal propagation (when consent is withdrawn, downstream access stops)

▸ Consent-aware APIs (queries only return data the caller is consented to access)

Patient Consent Interface

Patients interact with their consents through:

  • Mobile app (iOS/Android)
  • Web portal
  • Integration with your existing patient app (via API)

The interface shows:

  • Active consents in plain language
  • Data flowing under each consent
  • Access logs
  • Actions: modify, extend, withdraw

Provider/Insurer Consent Request Flow

When you need consent from a patient:

  1. Create consent request (specifying data types, purpose, duration)
  2. Request sent to patient via app notification / email / SMS
  3. Patient reviews in plain language, grants or declines
  4. If granted, consent activates immediately
  5. Consent reference available for your records
  6. Data begins flowing (if device is connected)

No paper. No scanning. No ambiguity.

The consent advantage

For Patients

  • Transparency: know who has your data
  • Control: grant, modify, withdraw at any time
  • Trust: deal with organisations that respect your choices

For Healthcare Providers

  • Governance: prove consent for every data use
  • Efficiency: no manual consent chasing
  • CQC confidence: consent architecture that demonstrates good practice

For Insurers

  • FCA readiness: defensible consent for health data use in commercial decisions
  • Member trust: transparent data practices differentiate in a sceptical market
  • Reduced liability: clear consent trail for every data-informed decision

For Digital Health

  • Scale: automated consent that works for 10 patients or 10 million
  • Compliance: GDPR Article 7 (conditions for consent) built in
  • Differentiation: consent UX that builds user trust

Built for regulatory reality

Regulation How We Align
GDPR / UK GDPR Consent is freely given, specific, informed, unambiguous ✓ Easy withdrawal ✓ Demonstrable (auditable) ✓ Separate for separate purposes ✓
ICO Expectations Granular options ✓ Plain language ✓ No pre-ticked boxes ✓ Easy withdrawal ✓ Records maintained ✓
FCA Clear explanation of data use ✓ Evidence of informed consent ✓ Audit trail for decisions ✓
CQC Patient involvement in decisions ✓ Clear consent processes ✓ Appropriate records ✓
NHS DSPT Standard 1: Data handled legally ✓ Standard 7: Shared appropriately ✓

Works with your existing consent processes

Not a rip-and-replace:

If you have existing consent processes, Inference Clinical can:

  • Digitise and structure existing paper consents
  • Link legacy consents to ongoing data flows
  • Run alongside your current approach while transitioning
  • Integrate with your patient portal / app

Standard APIs:

  • FHIR R4 Consent resources (read/write)
  • Consent verification endpoints
  • Webhook notifications for consent events
  • Bulk consent status queries

Consent request integration:

Embed consent requests in your existing patient journeys:

  • In-app consent flows
  • Web forms
  • SMS-triggered consent
  • Email consent links
  • Care team-assisted consent (witnessed verbal consent)

Ready to fix consent?

Whether you're preparing for FCA scrutiny of health data use, building patient trust in your digital services, or just tired of the consent governance headache — we should talk.

Book a Consent Architecture Review