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 Condition
- 3.3.6 Provenance.read
- 3.3.7 Provenance.search
- 3.3.8 Consent.create/read/patch
- 3.3.9 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/update/delete
- 3.10.2 Device read
- 3.10.3 DeviceUseStatement create/update
- 3.10.4 DeviceUseStatement read
- 3.11 Device/DeviceMetric/DeviceUseStatement - Work in Progress (will be in effect with next release)
- 3.11.1 Device/DeviceMetric create
- 3.11.2 Device/DeviceMetric update/delete
- 3.11.3 DeviceUseStatement create/update
- 3.11.4 DeviceUseStatement read
- 3.11.5 DeviceUseStatement search
- 3.12 Questionnaire
- 3.12.1 Questionnaire
- 3.13 Actionguidance
- 3.13.1 Actionguidance
- 3.14 View
- 3.14.1 View
- 3.15 Transform
- 3.16 Terminology: ConceptMap/CodeSystem/ValueSet/NamingSystem
- 3.17 Questionnaire Terminology: ConceptMap/CodeSystem/ValueSet/NamingSystem
- 3.18 Library
- 3.18.1 Library evaluate
- 3.19 Reports
- 3.19.1 Schedule/Fetch <Report_name>
- 3.20 Patient/Appointment/Communication(eHealthMessage)/Person
- 3.20.1 Patient.read
- 3.20.2 Patient.write
- 3.20.3 Patient$updatePatientWithSKRSData
- 3.20.4 Patient$createPatient
- 3.20.5 Appointment.read
- 3.20.6 Appointment.write
- 3.20.7 Appointment$exportAsiCal
- 3.20.8 RelatedPerson.read
- 3.20.9 RelatedPerson.write
- 3.20.10 Communication.read
- 3.20.11 Communication.write
- 3.20.12 Person$match
- 3.21 Group Appointment
- 3.22 Material Content (Storage-Service)
- 3.22.1 Material Content
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 | "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 | - |
System | - |
Read and Search operations do not require any security context apart from the privilege.
DocumentReference.create/update | |
User Type | Organization Context |
|---|---|
Practitioner / Patient | required: must match DocumentReference.custodian |
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 (Generic Material) | |||
User Type | FHIR Operation | Organization Context | Role needed |
|---|---|---|---|
Practitioner / Patient | create | required: Must match | owner |
update | required: Must match | owner | |
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 | create | - | required: |
update | - | required: | |
read | - | required: | |
search | - | required: | |
System | - | - | - |
EpisodeOfCare/Condition/Provenance/Consent
EpisodeOfCare cannot be created directly. They are 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 |
The patient | must not be present | required: must match EpisodeOfCare.Patient | - |
System | - | - | - |
EpisodeOfCare.read | |
User Type | EpisodeOfCare Context |
|---|---|
Practitioner/Patient | 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 | 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 |
|
System | - | - | - |
Condition | |||
User Type | EpisodeOfCare Context | Patient Context | CareTeam Context |
|---|---|---|---|
Practitioner | required: must match Condition.episodeOfCare | required: must match Condition.subject | - |
Patient | 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 | 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 | required: must match the EpisodeOfCare search parameter (provenance.target) | - |
System | - | - |
Consent.create/read/patch | |||
User Type | EpisodeOfCare Context | Patient context | CareTeam Context |
|---|---|---|---|
Practitioner | Required Must match data.reference | Required Must match data.patient | - |
Patient | Required Must match data.reference | Required Must match data.patient | - |
System | - | - | - |
Consent.search | ||
User Type | EpisodeOfCare Context | CareTeam Context |
|---|---|---|
Practitioner | required: must match the EpisodeOfCare search parameter (consent.data.reference) | - |
Patient | required: must match the EpisodeOfCare search parameter (consent.data.reference) | - |
System | - | - |
CarePlan/ServiceRequest/Communication(ehealth-material-communication)
ServiceRequest is considered a part of a CarePlan and does not have separate privileges.
CarePlan cannot be created directly. It is created and assigned to a Patient by calling PlanDefinition$apply
CarePlan/ServiceRequest Read/Suggest-care-teams | ||
User Type | EpisodeOfCare Context | |
|---|---|---|