This page is part of the FUT Infrastructure (v11.0.1: Release) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions

Resource Profile: ehealth-consent

Official URL: http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-consent				Version: 11.0.1
Active as of 2026-10-23				Computable Name: ehealth-consent

Introduction

A Consent resource is a record of a healthcare consumer’s policy choices, which permits or denies identified actors(s) or identified role(s) to perform one or more actions within a given policy context, for specific purpose(s) and period of time.

Scope and Usage

In the eHealth infrastructure a Consent resource is used

as a record of the fact that a Patient has given a Consent and
to enforce data policies that require Consent to be given and recorded for a Patient.

The eHealth profile of Consent has the following extensions:

ehealth-consent-affiliation which specifies the care context level to which the consent applies—either EpisodeOfCare level (mandatory reference) or CarePlan level (optional reference). See section on Affiliation below.

When a Patient gives a consent, this consent must be recorded as a Consent resource. This resource can be created by the Patient herself or by a Practitioner as a result of conversations or correspondence with the Patient.

eHealth operates with six categories of consents:

Category PITEOC: Consent given by a Patient to be enrolled into a telemedical EpisodeOfCare. This Consent is interpreted to also apply to all CarePlan instances related to the consented EpisodeOfCare.
Category SSLPCI: Consent given by a Patient to have his/her contact information (physical address and telecommunication endpoints) being disclosed to a specified actor supplying device(s) and service(s) to the Patient as part of an EpisodeOfCare and related CarePlan(s).
Category behavior-by-policy: A policy-driven behaviour marker that records whether an actor is permitted or denied a behaviour, where the concrete behaviour is identified by the Consent.policy.uri. Unlike PITEOC and SSLPCI, a behavior-by-policy Consent is not necessarily a consent given by the Patient — it is typically recorded by a Practitioner. The behaviour can be scoped to an EpisodeOfCare and/or a citizen-specific plan (CarePlan) by means of the ehealth-consent-affiliation extension. The policies that can be expressed are defined in the ValueSet ehealth-consent-policy. At present, the only defined policy controls whether triage results may be displayed to the Patient; additional policies may be added in the future. See Controlling display of triage results to the Patient and Affiliation below for details of that policy.
Category PORPI (Processing of RelatedPerson Information): Consent given by a RelatedPerson to have information about themselves, including their CPR number, stored and processed in the infrastructure. This is a precondition for a related person being able to log in and perform activities on behalf of the Patient. See Consents for related persons performing activities.
Category RPCTEOC (RelatedPerson Contributes to EpisodeOfCare): Consent given by a Patient to a specific RelatedPerson contributing measurement data to the Patient's EpisodeOfCare. See Consents for related persons performing activities.
Category AFPA: Blocks access for holders of parental authority (forældremyndighedsindehavere) to a specific EpisodeOfCare. Unlike PITEOC and SSLPCI, an AFPA Consent is not a consent given by the Patient but a deny decision recorded by the application solution (anvenderløsning). When an active AFPA Consent exists for an EpisodeOfCare, a parental authority holder (a RelatedPerson with relationship PARAUTH, see ehealth-relatedperson) cannot set that EpisodeOfCare as security context, and cannot read or search the EpisodeOfCare or its associated data. The block applies to all parental authority holders of the Patient.

Consents of category PITEOC are expressed by creating a Consent resource with:

Consent.category.coding.system = "http://ehealth.sundhed.dk/cs/consent-category"
Consent.category.coding.code = "PITEOC".

Consents of category SSLPCI are expressed by creating a Consent resource with:

Consent.category.coding.system = "http://ehealth.sundhed.dk/cs/consent-category"
Consent.category.coding.code = "SSLPCI".

Consents of category behavior-by-policy are expressed by creating a Consent resource with:

Consent.category.coding.system = "http://ehealth.sundhed.dk/cs/consent-category"
Consent.category.coding.code = "behavior-by-policy"
Consent.policy.uri set to the policy that defines the behaviour being decided. The policy must be one of those in the ValueSet ehealth-consent-policy - it is the policy that gives the Consent its concrete meaning.

Consents of category AFPA are expressed by creating a Consent resource with:

Consent.category.coding.system = "http://ehealth.sundhed.dk/cs/consent-category"
Consent.category.coding.code = "AFPA"

The remaining elements to set depend on the specific policy. For the currently defined policy, see Controlling display of triage results to the Patient below.

Controlling display of triage results to the Patient

A Consent of category behavior-by-policy with Consent.policy.uri = "http://ehealth.sundhed.dk/policy/ehealth/display-triage-result" is used to record the decision of whether triage results may be displayed to the Patient. The decision can be recorded at the EpisodeOfCare level and/or at the CarePlan level by use of the ehealth-consent-affiliation extension.

The eHealth infrastructure only stores this decision. It does not act on it, does not enforce it, and does not define any precedence between levels or any default behaviour. It is the responsibility of the consuming Telemedicine Solutions to read the Consent(s), to decide which level takes precedence when decisions exist at both the EpisodeOfCare and CarePlan level, and to decide how to behave when no applicable Consent exists. The infrastructure carries no opinion on these matters.

A Consent recording this decision is expressed with the following elements:

Element Value Description

Consent.category http://ehealth.sundhed.dk/cs/consent-category#behavior-by-policy Marks this Consent as expressing a behavior governed by a policy.

Consent.scope http://ehealth.sundhed.dk/cs/ehealth-consent-scope#behavior The scope of the Consent.

Consent.policy.uri http://ehealth.sundhed.dk/policy/ehealth/display-triage-result The policy being decided on, i.e. display of triage results.

Consent.extension[ehealth-consent-affiliation] Reference to EpisodeOfCare, and optionally also CarePlan The care context level(s) the decision applies to. See Affiliation.

Consent.patient Reference to the Patient The Patient who is the subject of this Consent.

Consent.provision.type permit Records that triage results may be displayed to the Patient.

Consent.provision.class http://hl7.org/fhir/resource-types#ClinicalImpression The type of data the decision is about.

Consent.provision.code http://ehealth.sundhed.dk/cs/clinicalimpression-codes#TriagingResult The specific kind of data the decision is about.

Consent.provision.period A (possibly open-ended) period The validity period of the decision. As with the decision itself, the infrastructure stores this period but does not act on or enforce it.

Consent.status active The infrastructure does not act on the status for this category, so deciding which statuses to treat as a current decision (e.g. only active) is the responsibility of the consuming Telemedicine Solution.

Element	Value	Description
`Consent.category`	`http://ehealth.sundhed.dk/cs/consent-category#behavior-by-policy`	Marks this Consent as expressing a behavior governed by a policy.
`Consent.scope`	`http://ehealth.sundhed.dk/cs/ehealth-consent-scope#behavior`	The scope of the Consent.
`Consent.policy.uri`	`http://ehealth.sundhed.dk/policy/ehealth/display-triage-result`	The policy being decided on, i.e. display of triage results.
`Consent.extension[ehealth-consent-affiliation]`	Reference to `EpisodeOfCare`, and optionally also `CarePlan`	The care context level(s) the decision applies to. See Affiliation.
`Consent.patient`	Reference to the Patient	The Patient who is the subject of this Consent.
`Consent.provision.type`	`permit`	Records that triage results may be displayed to the Patient.
`Consent.provision.class`	`http://hl7.org/fhir/resource-types#ClinicalImpression`	The type of data the decision is about.
`Consent.provision.code`	`http://ehealth.sundhed.dk/cs/clinicalimpression-codes#TriagingResult`	The specific kind of data the decision is about.
`Consent.provision.period`	A (possibly open-ended) period	The validity period of the decision. As with the decision itself, the infrastructure stores this period but does not act on or enforce it.
`Consent.status`	`active`	The infrastructure does not act on the status for this category, so deciding which statuses to treat as a current decision (e.g. only `active`) is the responsibility of the consuming Telemedicine Solution.

The elements above are those that give this policy its meaning; the list is not exhaustive. As for any Consent, additional elements should be set as appropriate. In particular, it is recommended to also set Consent.performer (the actor recording/agreeing the decision) and Consent.organization (the custodian Organization responsible for the Consent). These have been omitted from the above for brevity.

When the affiliation extension is used, the infrastructure validates the following on create and update — if any check fails, the Consent is rejected:

The Consent must carry the http://ehealth.sundhed.dk/policy/ehealth/display-triage-result policy.
Exactly one EpisodeOfCare affiliation must be present, and it must match the EpisodeOfCare in the creating Practitioner's security context.
Any CarePlan affiliation must reference a CarePlan whose CarePlan.episodeOfCare equals the affiliated EpisodeOfCare.

Accordingly, the affiliation level expresses where the decision applies:

An affiliation to only an EpisodeOfCare expresses a decision at the EpisodeOfCare level.
An affiliation to both an EpisodeOfCare and a CarePlan expresses a decision at the citizen-specific plan (CarePlan) level.

See Affiliation for the extension definition.

See Consent/23 for an example of a Consent that records the triage-result display decision.

Note that, unlike the policy-enforcing categories PITEOC and SSLPCI (see Enforcement of Consent below), a behavior-by-policy Consent does not use Consent.provision.data.reference to bind the Consent to an EpisodeOfCare/CarePlan. Using Consent.provision.data.reference would change the meaning of the Consent (it would state which data the consent is about); the care context level is instead expressed through the ehealth-consent-affiliation extension.

Access control

A Patient (citizen) is not allowed to create or update a Consent with policy http://ehealth.sundhed.dk/policy/ehealth/display-triage-result — the decision of whether triage results may be displayed to the Patient is controlled by a Practitioner. See Remarks on operations below.

A related person (Danish: pårørende) can be assigned as performer of activities on a Patient's CarePlan (see ServiceRequest.performer on ehealth-servicerequest and the $get-performer-activities operation). Two consents make this lawful, and both are recorded as Consent resources, typically by a Practitioner:

The related person's own consent to the infrastructure storing and processing information (including the person identifier, that is, the Danish CPR number) about the person as a related person to another person (the patient). Category PORPI.
The Patient's consent to the related person contributing measurement data to the Patient's EpisodeOfCare. Category RPCTEOC.

The information is carried by the category codes. No Consent.policy and no Consent.provision.action codes are defined for these consents; both elements are optional and are left empty.

A PORPI consent is expressed with the following elements:

Element Value Description

Consent.category http://ehealth.sundhed.dk/cs/consent-category#PORPI Marks this Consent as the related person's consent to processing of their information.

Consent.scope http://terminology.hl7.org/CodeSystem/consentscope#patient-privacy Agreement to collect, access, use or disclose information.

Consent.patient Reference to the Patient The Patient on whose behalf the related person is to perform activities. The Consent is stored in the Patient's context.

Consent.performer Reference to the RelatedPerson The related person giving the consent.

Consent.verification verified = true, verifiedWith = reference to the RelatedPerson, verificationDate = the date/time of verification Records that the consent has been verified with the related person.

Consent.provision.type permit The related person permits the processing.

Consent.provision.period A (possibly open-ended) period The period for which the consent is in force.

Consent.status active Only active consents are considered to be in force.

Element	Value	Description
`Consent.category`	`http://ehealth.sundhed.dk/cs/consent-category#PORPI`	Marks this Consent as the related person's consent to processing of their information.
`Consent.scope`	`http://terminology.hl7.org/CodeSystem/consentscope#patient-privacy`	Agreement to collect, access, use or disclose information.
`Consent.patient`	Reference to the Patient	The Patient on whose behalf the related person is to perform activities. The Consent is stored in the Patient's context.
`Consent.performer`	Reference to the `RelatedPerson`	The related person giving the consent.
`Consent.verification`	`verified` = `true`, `verifiedWith` = reference to the `RelatedPerson`, `verificationDate` = the date/time of verification	Records that the consent has been verified with the related person.
`Consent.provision.type`	`permit`	The related person permits the processing.
`Consent.provision.period`	A (possibly open-ended) period	The period for which the consent is in force.
`Consent.status`	`active`	Only active consents are considered to be in force.

Consent.provision.actor is not populated on a PORPI consent. The related person consents to everybody else processing their information; the related person is not themselves the actor controlled by the consent, and listing the Practitioners and Patient granted access would have to be kept up to date as further Practitioners gain access.

An RPCTEOC consent is expressed with the following elements:

Element Value Description

Consent.category http://ehealth.sundhed.dk/cs/consent-category#RPCTEOC Marks this Consent as the Patient's consent to a related person contributing to the EpisodeOfCare.

Consent.scope http://ehealth.sundhed.dk/cs/ehealth-consent-scope#contribution The related person contributes information on behalf of the Patient.

Consent.patient Reference to the Patient The Patient giving the consent.

Consent.verification verified = true, verifiedWith = reference to the Patient, verificationDate = the date/time of verification Records that the consent has been verified with the Patient.

Consent.provision.type permit The Patient permits the contribution.

Consent.provision.actor Reference to the RelatedPerson, role http://terminology.hl7.org/CodeSystem/v3-ParticipationType#CONT (Contact) The related person permitted to contribute.

Consent.provision.data.reference Reference to the EpisodeOfCare The EpisodeOfCare the related person may contribute to.

Consent.provision.period A (possibly open-ended) period The period for which the consent is in force.

Consent.status active Only active consents are considered to be in force.

Element	Value	Description
`Consent.category`	`http://ehealth.sundhed.dk/cs/consent-category#RPCTEOC`	Marks this Consent as the Patient's consent to a related person contributing to the EpisodeOfCare.
`Consent.scope`	`http://ehealth.sundhed.dk/cs/ehealth-consent-scope#contribution`	The related person contributes information on behalf of the Patient.
`Consent.patient`	Reference to the Patient	The Patient giving the consent.
`Consent.verification`	`verified` = `true`, `verifiedWith` = reference to the `Patient`, `verificationDate` = the date/time of verification	Records that the consent has been verified with the Patient.
`Consent.provision.type`	`permit`	The Patient permits the contribution.
`Consent.provision.actor`	Reference to the `RelatedPerson`, role `http://terminology.hl7.org/CodeSystem/v3-ParticipationType#CONT` (Contact)	The related person permitted to contribute.
`Consent.provision.data.reference`	Reference to the `EpisodeOfCare`	The EpisodeOfCare the related person may contribute to.
`Consent.provision.period`	A (possibly open-ended) period	The period for which the consent is in force.
`Consent.status`	`active`	Only active consents are considered to be in force.

As for the behavior-by-policy category, the elements above are those that give the consents their meaning; the list is not exhaustive. It is recommended to also set Consent.dateTime and Consent.organization (the custodian Organization responsible for the Consent).

The infrastructure stores these two consents but does not enforce them: assigning a RelatedPerson as ServiceRequest.performer is not conditional on either consent being present. It is the responsibility of the Telemedicine Solution to record the consents before assigning activities to a related person.

A RelatedPerson logged in does not necessarily have access to Consent resources. It is expected that a Practitioner will create, read, update and search consents when necessary.

See Consent/24 for an example PORPI consent and Consent/25 for an example RPCTEOC consent.

Business rules are built into eHealth infrastructure to ensure that data can only be processed or forwarded to other systems and actors when the proper Consent is given.

This means, that:

An EpisodeOfCare can only change status to active if a Consent with category PITEOC has been given.
An SSL Order can only change status to submitted if a Consent with category SSLPCI has been given.

In addition to the Consent.category element, the following elements must be set on a Consent resource for the policy enforcing business logic to take effect:

Consent.patient - the patient who is the subject of this consent (must coincide with the EpisodeOfCare.patient referenced by Consent.data.reference)
Consent.provision.data.reference - the EpisodeOfCare for which this Consent is in force.
Consent.provision.actor - the actor (Organization, CareTeam, Practitioner) whose behaviour is controlled by this consent.
Consent.status - the status of this consent (only active consents are considered to be in force)
Consent.provision.period - the (possibly open-ended) period for which this consent is in force.

For more information see the element descriptions in the snapshot table on this page and also see the example Consent resources on the Examples tab.

Affiliation

Specifies the care context level to which the consent applies—either EpisodeOfCare level (mandatory reference) or CarePlan level (optional reference). This enables precise scoping of consent in telemedicine solutions, such as controlling patient access to triage results for specific CarePlan or broader EpisodeOfCare. The Consent.provision.data element is for data controlled by the consent, while ehealth-consent-affiliation indicates the care level to which the consent applies. See Consent/23 for an example of how to use the affiliation extension.

Remarks on operations

Search

As patient user
- Search parameter patient is mandatory and must match the patient in the user context.
As practitioner user
- Search parameters most contain either data or affiliation that matches the episodeOfCare in the user context.
- Parameter affiliation:
  - If searching by affiliation for multiple CarePlans, the affiliation parameter must be specified two times ?affiliation=episodeOfCareRef&affiliation=careplanRef1,careplanRef2. A single OR search containing both episodeOfCareRef and CarePlanRefs is not allowed, as there is no guarantee the CarePlan is referencing the specified episodeOfCare.

Create

As patient user
- Not allowed to create Consent with policy http://ehealth.sundhed.dk/policy/ehealth/display-triage-result.

Update

As patient user
- Not allowed to update Consent with policy http://ehealth.sundhed.dk/policy/ehealth/display-triage-result.

Usages:

Refer to this Profile: ehealth-consent
Examples for this Profile: Consent/23, Consent/24 and Consent/25
CapabilityStatements using this Profile: careplan and patient

You can also check for usages in the FHIR IG Statistics

Formal Views of Profile Content

Description of Profiles, Differentials, Snapshots, and their representations.

Key Elements Table
Differential Table
Snapshot Table
Statistics/References
All

Name	Flags	Card.	Type	Description & Constraints Filter: Bindings Constraints Obligations
Consent	C	0..*	Consent	A healthcare consumer's choices to permit or deny recipients or roles to perform actions for specific purposes and periods of time Constraints: ppc-1, ppc-2, ppc-3, ppc-4, ppc-5
Consent.implicitRules	This element is a modifier element. This element is included in summaries.	0..1	uri	A set of rules under which this content was created
Consent.Slices for extension		0..*	Extension	Extension Slice: Unordered, Open by value:url Slicing Note: The rules on this element (including its children) apply to all the slices, but are not repeated in them
Consent.Slices for extension.extension:affiliation		0..*	Reference(ehealth-episodeofcare \| ehealth-careplan) {r }	Affiliation to EpisodeOfCare and optionally CarePlan URL: http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-consent-affiliation
Consent.modifierExtension	This element is a modifier element.	0..*	Extension	Extensions that cannot be ignored
Consent.status	This element is a modifier element. This element is included in summaries.	1..1	code	draft \| proposed \| active \| rejected \| inactive \| entered-in-error Binding: ConsentState (required): Indicates the state of the consent.
Consent.scope	This element is a modifier element. This element is included in summaries.	1..1	CodeableConcept	Specific scope covered by this consent Binding: Consent Scope (required)
Consent.category	This element is included in summaries.	1..*	CodeableConcept	Classification of the consent statement - for indexing/retrieval Binding: Consent Category (required)
Consent.patient	This element is included in summaries.	1..1	Reference(ehealth-patient) {r }	Who the consent applies to
Consent.organization	This element is included in summaries.	0..*	Reference(ehealth-organization) {r }	Custodian of the consent
Consent.Slices for source[x]	This element is included in summaries.	0..1		Source from which this consent is taken Slice: Unordered, Closed by type:$this Slicing Note: The rules on this element (including its children) apply to all the slices, but are not repeated in them Other type slices that contain no new information are not shown in this view
Consent.Slices for source[x].sourceAttachment			Attachment
Consent.Slices for source[x].sourceReference			Reference(Consent \| DocumentReference \| Contract \| QuestionnaireResponse)
Consent.Slices for source[x].source[x]:sourceReference	This element is included in summaries.	0..1	Reference(ehealth-consent \| ehealth-documentreference \| Contract \| ehealth-questionnaireresponse)	Source from which this consent is taken
Documentation for this format

Terminology Bindings

Path	Status	Usage	ValueSet	Version	Source
Consent.status	Base	required	ConsentState	📍4.0.1	FHIR Std.
Consent.scope	Base	required	Consent Scope	📦11.0.1	This IG
Consent.category	Base	required	Consent Category	📦11.0.1	This IG

Constraints

Grade

Path(s)

Description

Expression

Name	Card.	Type	Description & Constraints Filter: Bindings Constraints Obligations
Consent	0..*	Consent	A healthcare consumer's choices to permit or deny recipients or roles to perform actions for specific purposes and periods of time
Consent.Slices for extension	0..*	Extension	Extension Slice: Unordered, Open by value:url Slicing Note: The rules on this element (including its children) apply to all the slices, but are not repeated in them
Consent.Slices for extension.extension:affiliation	0..*	Reference(ehealth-episodeofcare \| ehealth-careplan) {r }	Affiliation to EpisodeOfCare and optionally CarePlan URL: http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-consent-affiliation
Consent.scope	1..1	CodeableConcept	Specific scope covered by this consent Binding: Consent Scope (required)
Consent.category	1..*	CodeableConcept	Classification of the consent statement - for indexing/retrieval Binding: Consent Category (required)
Consent.patient	1..1	Reference(ehealth-patient) {r }	Who the consent applies to
Consent.organization	0..*	Reference(ehealth-organization) {r }	Custodian of the consent
Consent.Slices for source[x]	0..1	Attachment, Reference(Consent \| DocumentReference \| Contract \| QuestionnaireResponse)	Source from which this consent is taken Slice: Unordered, Open by type:$this Slicing Note: The rules on this element (including its children) apply to all the slices, but are not repeated in them Other type slices that contain no new information are not shown in this view
Consent.Slices for source[x].source[x]:sourceReference	0..1	Reference(ehealth-consent \| ehealth-documentreference \| Contract \| ehealth-questionnaireresponse)	Source from which this consent is taken
Consent.policy
Consent.policy.uri	0..1	uri	Specific policy covered by this consent Binding: Consent Policy (required)
Consent.provision
Consent.provision.class	0..*	Coding	Specific class covered by this consent Binding: Consent Provision Class (required)
Consent.provision.code	0..*	CodeableConcept	Specific code covered by this consent Binding: Consent Provision Code (required)
Documentation for this format

Terminology Bindings (Differential)

Path	Status	Usage	ValueSet	Version	Source
Consent.scope	Base	required	Consent Scope	📦11.0.1	This IG
Consent.category	Base	required	Consent Category	📦11.0.1	This IG
Consent.policy.uri	Base	required	Consent Policy	📦11.0.1	This IG
Consent.provision.class	Base	required	Consent Provision Class	📦11.0.1	This IG
Consent.provision.code	Base	required	Consent Provision Code	📦11.0.1	This IG

Description & Constraints Filter:

Consent

0..*

Consent

A healthcare consumer's choices to permit or deny recipients or roles to perform actions for specific purposes and periods of time
Constraints: ppc-1, ppc-2, ppc-3, ppc-4, ppc-5

0..1

Logical id of this artifact