Admin: Automated edit (via update-page on MediaWiki MCP Server)

2026-07-06T04:00:28Z

Automated edit (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 09:30, 6 July 2026
Line 109:		Line 109:

	Care's consent aligns with the FHIR '''Consent''' resource: its status, category, decision, and validity period map to their FHIR counterparts, modelling a patient's recorded choice to permit or deny a category of activity.		Care's consent aligns with the FHIR '''Consent''' resource: its status, category, decision, and validity period map to their FHIR counterparts, modelling a patient's recorded choice to permit or deny a category of activity.

			{{Navbox clinical}}

	{{Related}}		{{Related}}
			Wiki: ohcnwiki.tellmey.fyi

Admin: OHC identity seed

2026-07-04T22:43:09Z

OHC identity seed

New page

{{Doc header
|type=concept
|domain=clinical
|title=Consent
|order=12
|introduced=3.0
|fhir=Consent
|concept=Concepts/Patient
|reference=References/Permission
}}

A '''consent''' records a patient's decision to permit or refuse a category of activity — treatment, research participation, sharing of their information, or a directive about end-of-life care. It is the auditable proof that a choice was made, by or for the patient, before that activity went ahead.

== What it represents ==

In Care's FHIR-aligned model, a consent maps to the '''Consent''' resource. Each record answers four questions:

* '''What is being decided''' — a category such as treatment, research, privacy of information, or an advance directive like a do-not-resuscitate order
* '''What was decided''' — a single decision to ''permit'' or ''deny'' it
* '''When it applies''' — the date it was recorded, plus an optional validity window
* '''How it was confirmed''' — who witnessed the decision and how, with any signed form attached alongside

The key thing to understand is that a consent is ''not'' a permission setting. It does not grant anyone access to the system. It documents the '''patient's''' clinical and legal choice — a fact about the patient's care, not a rule about staff. Who can act in Care is governed separately by the [[References/Permission|permission model]].

== Lifecycle ==

A consent's status mirrors whether its decision is currently in force:

<syntaxhighlight lang="text">draft → active → inactive
↘ not_done
↘ entered_in_error</syntaxhighlight>
* '''draft''' — recorded but not yet in force
* '''active''' — in force; the decision currently governs the activity
* '''inactive''' — no longer in force, for example once its validity window has passed
* '''not_done''' — the consent activity never took place
* '''entered_in_error''' — recorded by mistake; kept for audit but disregarded

Status is a plain field on the record. Moving a consent to <code>entered_in_error</code> corrects the history without deleting it, and changing status has no automatic side effect elsewhere in the chart — nothing downstream is unlocked or revoked.

== Categories ==

The category names what the patient is deciding about. Care recognises seven:

{| class="wikitable"
|-
! Category
! What it covers
|-
| Treatment
| Consent to a clinical treatment or procedure
|-
| Research
| Consent to take part in research
|-
| Patient privacy
| Consent to disclose or share the patient's information
|-
| DNR
| A do-not-resuscitate directive
|-
| Comfort care
| A comfort or palliative care directive
|-
| Advance care directive
| A directive about future care while the patient can still decide
|-
| Advance directive (other)
| Any other advance directive
|}

Every consent carries exactly one decision — '''permit''' or '''deny''' — so a refusal is captured with the same weight and auditability as an approval. A documented "no" is as much a part of the record as a "yes".

== How it connects ==

A consent is always attached to a single [[Concepts/Encounter|encounter]], and the owning [[Concepts/Patient|patient]] is reached through that encounter. The encounter is fixed at creation and cannot be moved to a different visit later — this is deliberate, because it preserves ''when and in what context'' the decision was made.

Two neighbouring records hang off a consent:

* '''Documents''' — a signed consent form or scanned file can be attached, so the paper trail lives beside the structured record
* '''Verifiers''' — each verification names the user who confirmed the consent, so a reviewer can later see exactly who witnessed it

== Permissions ==

There is no separate consent permission set. Because a consent always hangs off an encounter, it is governed by the '''encounter''' clinical-data permissions, with patient-level clinical-data access also accepted for reads.

{| class="wikitable"
|-
! Permission
! Description
! System Roles
|-
| <code>can_write_encounter_clinical_data</code>
| Create, update, or delete a consent on an encounter, and add or remove its verifications (blocked once the encounter is closed)
| Admin, Doctor, Nurse, Facility Admin
|-
| <code>can_view_clinical_data</code>
| View a patient's clinical record, including their consents
| Staff, Doctor, Nurse, Admin, Facility Admin
|-
| <code>can_read_encounter_clinical_data</code>
| Read consents via the encounter when patient-level clinical-data access is absent
| Admin, Doctor, Nurse, Facility Admin
|}

Roles are granted through organization, facility, or patient memberships, and permissions cascade down the organization tree — a role held higher up applies to the patients and consents beneath it.

== FHIR reference ==

Care's consent aligns with the FHIR '''Consent''' resource: its status, category, decision, and validity period map to their FHIR counterparts, modelling a patient's recorded choice to permit or deny a category of activity.

{{Related}}

Concepts/Consent - Revision history

Admin: Automated edit (via update-page on MediaWiki MCP Server)

Admin: OHC identity seed