App Consent Profile¶

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

Simple app consent profile: Patient X consented/refused to share information with Application Y (represented as a Device). This profile models consent for a patient to sign up with an app.

Overview

The Nexus EMR Core App Consent profile records one fact: patient X consented to, or refused, sharing information with application Y. The application is a Device conforming to NexusEmrCoreAppDevice, referenced from provision.actor.reference, so the app registration must exist before the consent that names it.

This page is an orientation. The full design — the grant/deny patterns, the status-to-display mapping, and complete worked JSON — is in the App Consent feature overview.

Two sibling profiles live on Consent

Consent carries two unrelated NexusEmr profiles, and meta.profile is what tells them apart:

app-consent — may this application receive this patient's data. Keyed on the app, as a Device reference in provision.actor.
item-consent — does the clinic have consent for a catalogue item (email, SMS, AI scribe) for this patient. Keyed on a code in category.

The two constrain the same elements differently, so validating against the wrong sibling produces failures that read like modelling errors rather than a mis-chosen profile. App consent pins category to a single fixed CodeableConcept, v3-ActCode#INFA; item consent slices category and requires an item slice whose coding comes from the NexusEmr consent-item CodeSystem. Check meta.profile before validating, and select by category when searching: an INFA category token returns app consents and excludes item consents by construction.

Where the decision lives, and what is pinned

provision is 1..1 MS and the decision is read from it together with status, following R4 exactly: provision.type is not permitted in the root provision, so a root provision with no type is a grant, and a refusal adds a nested provision with type = deny. status = proposed means the decision has not been made yet. provision.actor is 1..1 with role 1..1 (the app is the information recipient) and reference 1..1, restricted to Reference(NexusEmrCoreAppDevice). A consumer that reads only status will therefore report a refusal as a grant — the nested deny has to be checked — and the sibling item-consent profile deliberately does not use this pattern, so the same code cannot serve both.

Three elements are pinned, each 1..1 MS and bound required to its HL7 value set:

category = http://terminology.hl7.org/CodeSystem/v3-ActCode#INFA ("information access")
scope = http://terminology.hl7.org/CodeSystem/consentscope#patient-privacy
policyRule = http://terminology.hl7.org/CodeSystem/consentpolicycodes#cric

They are pinned as fixed CodeableConcepts, which is a deep equality test — the display string is part of the match, so the right system and code with a different display still fails. Copy the coding from the published examples verbatim. scope and policyRule carry no per-resource meaning: they satisfy R4's requirements (constraint ppc-1 needs one of policy or policyRule), and no consumer should read the decision out of them.

Exposure and identifiers

The profile is exposed to SMART apps read-only (consent:read): the app-consent record is the evidence that an application was authorized, so write and delete are withheld. SMART exposure is declared per resource type, so item-consent is read-only for the same reason.

identifier is 0..* with system and value both 1..1 when present. Carry the originating system's identifier where one exists, rather than only a locally generated one. That was a warning-severity invariant (app-consent-has-raw-identifier) until 1.21.0, which removed it; the recommendation stands, unchecked.

sourceAttachment is 0..1 and may carry the signed consent form inline. Item-consent takes the opposite position and removes the Attachment choice entirely, so do not carry a habit from one profile to the other.

Terminology bindings

Path	Strength	Value set
`Consent.status`	required	consent-state-codes
`Consent.scope`	required	consent-scope
`Consent.category`	required	consent-category
`Consent.category`	required	Consent Families Value Set
`Consent.provision.type`	required	consent-provision-type