Nexus EMR Item Consent Profile Core Profile

Canonical	../StructureDefinition/nexus-emr-core-item-consent
Status	draft · 1.26.0
Base	Consent (constraint)
Source	FSH · JSON

Patient-level consent for one catalogue item — whether the clinic may email the patient, text the patient, or use an AI scribe during their visit. Recorded manually by clinic staff from what the patient tells them, not captured through a patient-facing flow.

Overview

One Consent resource exists per (patient, item) and is updated in place as the patient changes their mind. category identifies the item and is the lookup key; provision.type carries the decision -- permit is Provided, deny is Declined -- and status says only whether the record is operative.

This profile used to carry its answer in status alone. That made an active item consent mean permission while an active privacy directive means a restriction in force, across resources sharing a resource type, a scope and a search. Every Consent profile in this guide now states its decision in the same element.

Overview

The Nexus EMR Core Item Consent profile records the patient's standing answer for one catalogue item — whether the clinic may email the patient, text the patient, or use an AI scribe during their visit. Clinic staff record it from what the patient tells them; there is no patient-facing flow. Exactly one Consent exists per (patient, item) pair and is updated in place, so the decision history is the resource's own FHIR version history, read through _history and vread.

This page is an orientation. The full design — state mapping, write path, evidence handling, history and migration requirements — is in the Item Consent feature overview.

Two sibling profiles live on Consent

Consent carries two unrelated NexusEmr profiles, distinguished by meta.profile:

• item-consent — patient-level consent for a catalogue item, keyed on a code in category.
• app-consent — whether a named application may receive this patient's data, keyed on a Device reference in provision.actor.

They constrain the same elements differently, so validating against the wrong sibling produces failures that look like modelling errors. App consent pins category to the single fixed CodeableConcept v3-ActCode#INFA; item consent slices category (1..*, open slicing, discriminated on coding.system) and requires a 1..1 item slice with exactly one coding from ../CodeSystem/nexus-consent-item. Additional categories may travel alongside the item slice, but only the item coding identifies the item. The item binding is extensible because tenant-defined catalogues are expected later, so consumers must tolerate an unfamiliar item code.

The decision is status, and only status

status is 1..1 MS, bound required to the R4 consent-state codes, and three of them carry meaning here:

• active — Provided
• rejected — Declined, covering both an initial refusal and a later revocation
• entered-in-error — the record should not exist; not a decision

Absence of a Consent for a (patient, item) pair means Not Recorded. Show it distinctly from Declined, but gate on it identically: no record is not permission. draft, proposed and inactive are legal against the binding but are never written and carry no defined meaning; the item-consent-status-is-defined invariant warns on them, since a binding cannot express that narrowing. active and rejected may alternate any number of times, in either direction.

provision is 0..1, reserved and unused. Consumers MUST NOT read consent or refusal out of it, and in particular must not expect app-consent's nested provision.type = deny pattern here.

Attribution, evidence, and finding the resource

performer is 0..1, restricted to Reference(NexusEmrCorePatient | NexusEmrCorePractitioner | NexusEmrCorePractitionerRole), with performer.display must-support because attribution is rendered from the display text. It stays optional only so older versions still conform; the item-consent-performer-is-attributable invariant warns when it or its display is missing. Set it on every status change, or the displayed attribution lags on whoever recorded the previous one.

Evidence uses sourceReference, and source[x] is narrowed to Reference(NexusEmrCoreDocumentReference) — the Attachment choice is removed from the type itself, so a resource carrying sourceAttachment fails validation, which keeps the document behind its own read permission. The optional nexus-consent-status-reason extension (0..1, free text) explains the current status and travels with the version it was written on.

Look a resource up by patient plus item coding:

GET Consent?patient={id}&category=../CodeSystem/nexus-consent-item|{code}

At most one resource comes back, and that same search is the write path: a conditional update against it skips the read, creating on the first decision and adding a version on every later one. The nexus-item-consent-identifier namespace, whose values composed the Patient's logical id with the item code, is retired — a logical id is a server address rather than a business identifier, so a re-ingest, a store migration or a copy between deployments leaves a recorded value naming an id that no longer exists. Read such a value where it appears; do not recompute one, match on one, or write a new one. Like app-consent, the profile is exposed to SMART apps read-only (consent:read).

Terminology bindings

Path	Strength	Value set
Consent.status	required	consent-state-codes
Consent.scope	required	consent-scope
Consent.category	extensible	Nexus EMR Consent Items
Consent.category	required	Consent Families Value Set
Consent.provision.type	required	consent-provision-type