Consent — Patient authorizations

Research, sharing, treatment, opt-in/opt-out: everything the patient authorizes or refuses, under what jurisdiction, with what granularity — machine-executable.

Purpose

Consent encodes the patient's wishes: who gets access to their data, for what purpose, for what period, on what data subset. R5 rewrote Consent around decision (permit/deny) and a single hierarchical provision. A Consent can be: opt-in (default allow + deny provisions), opt-out (default deny + permit provisions), or a specific form (research, advance-directive).

Key fields

Provisions and deny/permit logic

R5 simplified: a single global decision (permit or deny) and provision[] that restrict or broaden it. Each provision lists actor, action, securityLabel, purpose, class, code, dataPeriod, data — any data matching ALL these criteria falls under the provision.

JSON example

Research consent, 5 years, 2020-2026 data, access to research Org X:

{
  "resourceType": "Consent",
  "id": "share-research-001",
  "status": "active",
  "category": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/consentcategorycodes",
      "code": "research",
      "display": "Research Information Access"
    }]
  }],
  "subject": { "reference": "Patient/doe-john" },
  "date": "2026-05-15",
  "grantor": [{ "reference": "Patient/doe-john" }],
  "decision": "permit",
  "controller": [{ "reference": "Organization/hospital-1" }],
  "sourceAttachment": [{
    "url": "https://docs.hospital-1.example.org/consent/2026-05-15-001.pdf",
    "contentType": "application/pdf",
    "title": "Signed consent form"
  }],
  "regulatoryBasis": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/consentpolicycodes",
      "code": "cric"
    }]
  }],
  "provision": {
    "period": {
      "start": "2026-05-15",
      "end": "2031-05-15"
    },
    "actor": [{
      "role": {
        "coding": [{
          "system": "http://terminology.hl7.org/CodeSystem/v3-RoleCode",
          "code": "PROV",
          "display": "healthcare provider"
        }]
      },
      "reference": { "reference": "Organization/research-center-x" }
    }],
    "action": [{
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/consentaction",
        "code": "access"
      }]
    }],
    "purpose": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason",
      "code": "HRESCH",
      "display": "healthcare research"
    }],
    "dataPeriod": {
      "start": "2020-01-01",
      "end": "2026-05-15"
    }
  }
}

Common pitfalls

• Confusing active and permit — status is the lifecycle, decision the meaning (permit/deny).
• No regulatoryBasis — without regulatory basis (GDPR art. 9, HIPAA), the consent is legally weak.
• Overbroad provisions — a permit + action=access provision without purpose restriction is an open bar.
• No sourceAttachment — without the signed PDF the Consent is just a declaration with no proof.
• Migration from R4 — the R4 model (scope + provision.type) was replaced by unified decision + provision. Non-trivial refactor.

Related resources

• Patient — typical subject.
• Contract — broader legal use.
• Provenance — traceability.
• AuditEvent — access audit.
• DocumentReference — signed form.