Access Control in eHealth Services
Access to eHealth services and data in the eHealth Infrastructure is controlled through token-based authentication and authorization. The security model is described at Token Based Security .
eHealth Infrastructure services use fields in JWT access tokens to perform access control. This access control combines Role Based Access Control (RBAC) and Attribute Based Access Control (ABAC).
Content on this page
- 1 Content on this page
- 2 Role-Based Access Control
- 3 Attribute-Based Access Control
- 3.1 PlanDefinition/ActivityDefinition
- 3.2 DocumentReference
- 3.3 EpisodeOfCare/Condition/Provenance/Consent
- 3.3.1 EpisodeOfCare.create-episode-of-care
- 3.3.2 EpisodeOfCare.read
- 3.3.3 EpisodeOfCare.patch/updateCareteams
- 3.3.4 EpisodeOfCare.search
- 3.3.5 EpisodeOfCare.search (cross-team search)
- 3.3.6 Condition
- 3.3.7 Provenance.read
- 3.3.8 Provenance.search
- 3.3.9 Consent.create/read/patch
- 3.3.10 Consent.search
- 3.4 CarePlan/ServiceRequest/Communication(ehealth-material-communication)
- 3.5 Goal
- 3.5.1 Goal Create/Read/Update
- 3.5.2 Goal Search
- 3.6 CommunicationRequest
- 3.7 ClinicalImpression/Task
- 3.8 Observation/QuestionnaireResponse/Media/Communication (ehealth-communication)
- 3.8.1 Communication read
- 3.8.2 Communication create/patch
- 3.8.3 Communication search
- 3.8.4 Observation read
- 3.8.5 Observation search
- 3.8.6 QuestionnaireResponse read
- 3.8.7 QuestionnaireResponse search
- 3.8.8 QuestionnaireResponse (status in progress) create/update
- 3.8.9 Media read
- 3.8.10 Media search
- 3.8.11 $submit-measurement
- 3.8.12 $search-measurements
- 3.8.13 $search-measurements-bundle-limit
- 3.9 Organization/Practitioner/CareTeam
- 3.10 Device/DeviceMetric/DeviceUseStatement
- 3.10.1 Device/DeviceMetric create
- 3.10.2 Device/DeviceMetric update/delete
- 3.10.3 DeviceUseStatement create/update
- 3.10.4 DeviceUseStatement read
- 3.10.5 DeviceUseStatement search
- 3.11 Questionnaire
- 3.11.1 Questionnaire
- 3.12 Actionguidance
- 3.12.1 Actionguidance
- 3.13 View
- 3.13.1 View
- 3.14 Transform
- 3.15 Terminology: ConceptMap/CodeSystem/ValueSet/NamingSystem
- 3.16 Questionnaire Terminology: ConceptMap/CodeSystem/ValueSet/NamingSystem
- 3.17 Library
- 3.17.1 Library evaluate
- 3.18 Reports
- 3.18.1 Schedule/Fetch <Report_name>
- 3.19 Patient/Appointment/Communication(eHealthMessage and ehealthCareCommunication)/Person
- 3.19.1 Patient.read
- 3.19.2 Patient.write
- 3.19.3 Patient$updatePatientWithSKRSData
- 3.19.4 Patient$createPatient
- 3.19.5 Appointment.read
- 3.19.6 Appointment.write
- 3.19.7 Appointment$exportAsiCal
- 3.19.8 RelatedPerson.read
- 3.19.9 RelatedPerson.write
- 3.19.10 Communication.read
- 3.19.11 Communication.write
- 3.19.12 CareCommunication.read
- 3.19.13 CareCommunication.write
- 3.19.14 Person$match
- 3.20 Group Appointment
- 3.21 Material Content (Storage-Service)
- 3.21.1 Material Content
- 3.22 Assisted Login (Keycloak API)
- 3.23 BI platform
Role-Based Access Control
The RBAC part of the access control is based on the user’s list of process privileges contained in the access token.
Access Token Field | Meaning | Example Value |
|---|---|---|
realm_access | List of process privileges, that is, what is the user allowed to do. | "realm_access": {
"roles": [
"Patient.read",
"Patient.write"
]
} |
What operations the user is allowed to invoke is stated in the "realm_access" attribute. In the example above the user is allowed to issue a "Patient.read" and a "Patient.write". This means that the user can get and edit patient records. This part of the security model is the RBAC part, as the claims here are entirely based on what role the user has.
Attribute-Based Access Control
The ABAC part of the access control combines the access token user type with security token context(s) and, at times, also the access token user id. These are typically compared to attributes of the data from the services.
Access Token Field | Meaning | Example Value |
|---|---|---|
context | List of items that are set in context. context in combination with items in realm_access governs the access to all resources in the eHealth infrastructure. | "context": {
"organization_id" : "https://fut.com/fhir/Organization/1",
"care_team_id": https://fut.com/fhir/CareTeam/4,
"episode_of_care_id": https://fut.com/fhir/EpisodeOfCare/10,
"patient_id": "https://fut.com/fhir/Patient/8"
} |
user_id | Id of the user. Can be either an FHIR patient Id, FHIR practitioner Id or a KeyCloak ID | "user_id": " e03ccef7-b0b1-4f68-8e16-6fc2f865a922" |
user_type | Can be either SYSTEM, PATIENT, PRACTITIONER or SSL (As per Release 2026.3): | "user_type": "PATIENT" |
Each resource type (see IG Profiles) has certain restrictions to what context is required to allow data retrieval or data manipulation.
PlanDefinition/ActivityDefinition
These resources are not patient-related. Read and Search operations do not require any security context apart from the privilege.
PlanDefinition/ActivityDefinition | |||
User Type | FHIR Operation | Organization Context | Property updated → role needed |
|---|---|---|---|
Practitioner | create/update | required: must match modifierRole.reference | PlanDefinition/ActivityDefinition creation or modifierRole changed → owner All other updates → owner or co-author |
System | - | - | - |
PlanDefinition$apply | |||
User Type | EpisodeOfCare Context | CareTeam Context | |
|---|---|---|---|
Practitioner | required: Must match EpisodeOfCare.id | required: Must match EpisodeOfCare.team | |
System | - | - | |
DocumentReference
Instructional Material
These resources are not patient-related.
DocumentReference.read/search | |
User Type | Context |
|---|---|
Practitioner / Patient (As per Release 2026.3): | - |
System | - |
Read and Search operations do not require any security context apart from the privilege.
DocumentReference.create/update | |
User Type | Organization Context |
|---|---|
Practitioner | required: must match DocumentReference.custodian |
(As per Release 2026.3): | - |
System | - |
Material for Citizens
These resources are patient-related but not always patient-specific. The odd looking prefix emdr is an abbreviation ehealth-material-documentreference. It is needed as multiple profiles of DocumentReference are in use in the eHealth Infrastructure.
emdr-DocumentReference.create/update/read/search (General Material) | |||
User Type | FHIR Operation | Organization Context | Role needed |
|---|---|---|---|
Practitioner | create | required: Must match | owner |
update | required: Must match | owner | |
(As per Release 2026.3): | read/search | - | - |
System | - | - | - |
emdr-DocumentReference.create/update/read/search (Patient-Specific Material) | |||
User Type | FHIR Operation | EpisodeOfCare Context | Patient Context |
|---|---|---|---|
Practitioner | create | required: | required: |
update | required: | required: | |
read | required: | required: | |
search | required: | required: | |
Patient (As per Release 2026.3): | create | - | required: |
update | - | required: | |
read | - | required: | |
search | - | required: | |
System | - | - | - |
EpisodeOfCare/Condition/Provenance/Consent
EpisodeOfCare cannot be created directly. An EpisodeOfCare is created by calling the custom operation: create-episode-of-care.
EpisodeOfCare.create-episode-of-care | |||
User Type | EpisodeOfCare Context | Patient Context | CareTeam Context |
|---|---|---|---|
Practitioner | must not be present | required: must match EpisodeOfCare.patient | required: Must match EpisodeOfCare.team |
Patient (As per Release 2026.3): | must not be present | required: must match EpisodeOfCare.patient | - |
System | - | - | - |
EpisodeOfCare.read | |
User Type | EpisodeOfCare Context |
|---|---|
Practitioner/Patient (As per Release 2026.3): | required: must match EpisodeOfCare |
System | - |
EpisodeOfCare.patch/updateCareteams | ||
User Type | EpisodeOfCare Context | CareTeam Context |
|---|---|---|
Practitioner | required: must match EpisodeOfCare | required: Must match EpisodeOfCare.team |
Patient (As per Release 2026.3): | required: must match EpisodeOfCare | - |
System | - | - |
EpisodeOfCare.search | |||
User Type | EpisodeOfCare Context | Patient Context | CareTeam Context |
|---|---|---|---|
Practitioner | must not be present | optional but when present: must match the Patient search parameter | required: Must match CareTeam search parameter |
Patient | must not be present | Always present: must match the Patient search parameter |
|
(As per Release 2026.3): RelatedPerson | must not be present | required: must match the Patient search parameter | - |
System | - | - | - |
EpisodeOfCare.search (cross-team search) |
| |||
User Type | EpisodeOfCare Context | Patient Context | CareTeam Context | Comment |
|---|---|---|---|---|
Practitioner | must not be present | optional but when present: must match the Patient search parameter | - |
|
Condition |
| |||
User Type | EpisodeOfCare Context | Patient Context | CareTeam Context |
|
|---|---|---|---|---|
Practitioner | required: must match Condition.episodeOfCare | required: must match Condition.subject | - |
|
Patient (As per Release 2026.3): | required: must match Condition.episodeOfCare | required: must match Condition.subject | - | - |
System | - | - | - |
|
Provenance.read | ||
User Type | EpisodeOfCare Context | CareTeam Context |
|---|---|---|
Practitioner | required: must match Provenance.target | - |
Patient (As per Release 2026.3): | required: must match Provenance.target | - |
System | - | - |
Provenance.search | ||
User Type | EpisodeOfCare Context | CareTeam Context |
|---|---|---|
Practitioner | required: must match the EpisodeOfCare search parameter (provenance.target) | - |
Patient (As per Release 2026.3): | required: must match the EpisodeOfCare search parameter (provenance.target) | - |
System | ||