Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

...

...

...

...

...

...

...

...

...

Excerpt

Access to eHealth services and eHealth data in the eHealth Infrastructure are

...

controlled by authentication and authorization based on tokens.

...

The Token based security is described in Token Based Security. This page described how services in the eHealth Infrastructure rely on fields in the JWT access token to perform the access control. This access control comprises Role

...

Based Access Control (RBAC) and Attribute Based Access Control (ABAC).

Content on this page

Table of Contents

Role-Based Access Control

...

Access Token Field

Meaning

Example Value

realm_access

List of process privileges, that is, what is the user allowed to do.

Code Block
languagejson
"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.

...

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.

Code Block
languagejson
"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. 

...

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

-

-

...

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

-

...

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

-

-

...

Goal Search

User Type

Patient Context

EpisodeOfCare Context

CareTeam Context


Practitioner

-

required:

must match search param: addresses.episodeOfCare

required:

must match search param addresses.episodeOfCare.team or Careplan.careteam for the CarePlan that the addresses ServiceRequest belongs to.

Patient

required:

Must match search param addresses.subject

-

-



System

-

-

-



CommunicationRequest

CommunicationRequest Create/Read/Update/Delete

User Type

EpisodeOfCare Context

Patient Context

CareTeam Context

Details

Practitioner

required

must match CommunicationRequest.episodeOfCare

required

must match CommunicationRequest.subject

required

must match CommunicationRequest.recipient if the recipient contains a careteam



Patient

optional but when present:

must match CommunicationRequest.episodeOfCare


required

must match CommunicationRequest.subject

-

Update: Only status


System

-


-


CommunicationRequest Search

User Type

EpisodeOfCare Context

Patient Context

CareTeam Context


Practitioner

required if the searchparam recipient is a patient. 

optional otherwise.

must match searchparam CommunicationRequest.episodeOfCare when present

optional but when present:

must match searchparam CommunicationRequest.subject

required if searchparam recipient is a careteam



Patient

optional but when present

must match CommunicationRequest.episodeOfCare

Always present and must match searchparam CommunicationRequest.recipient

-



System

-

-

-


Draft of FUTURE change as a consequence of CCR154: CommunicationRequest Create/Read/Update/Delete

User Type

EpisodeOfCare Context

Patient Context

CareTeam Context

Details

Practitioner

CommunicationRequest.episodeOfCare and EpisodeOfCare security token context must match.

If CommunicationRequest.episodeOfCare is null then the security token must not have an episodeOfCare context

required

must match CommunicationRequest.subject

required

must match CommunicationRequest.recipient if the recipient contains a careteam

Patient

optional but when present it must match CommunicationRequest.episodeOfCare

If CommunicationRequest.episodeOfCare is null then the security token must not have an episodeOfCare context

required

must match CommunicationRequest.subject

-

Update: Only status

System

-

-

Draft of FUTURE change as a consequence of CCR154: CommunicationRequest Search

User Type

EpisodeOfCare Context

Patient Context

CareTeam Context

Practitioner

If EpisodeOfCare context is present, then searchparam and context must match

If EpisodeOfCare context is not present, then the search parameter must include at least one of:

  1. episodeOfCare:missing=true

  2. recipient=<careteam> matching CareTeam context

optional but when present:

must match searchparam patient

required if the search param recipient is a careteam. The search param and careteam context must match.

Patient

optional but when present

must match searchparam: episodeOfCare

Always present and must match searchparam CommunicationRequest.recipient

-

System

-

-

-

...

ClinicalImpression.search

User Type

EpisodeOfCare Context

Patient Context

CareTeam Context


Practitioner

optional but when

when present:must

  • do not need to match searchparam: episodeOfCare

optional

must match searchparam: subject

Only checked if EOC context is not present:

required:

either searchparam: episodeOfCare or searchparam: careplan must be provided:

  • if searchparam: episodeOfCare is provided: CareTeam context must be in EpisodeOfCare.team for all referenced EpisodeOfCare ids

  • if searchparam: careplan is provided: CareTeam context must be in CarePlan.careTeam for all referenced CarePlan.


Patient

optional but when present:

must match searchparam: episodeOfCare

required when EpisodeOfCare Context is not present:

must match searchparam: subject


-



System

-

-

-


...

Task create/read/update

User Type

EpisodeOfCare Context

Patient Context

CareTeam Context  / UserId

Extra Permission

Practitioner

optional but when present:

must match Task.episodeOfCare

optional, but when present:

must match Task.episis odeOfCareepisodeOfCare.subject

CareTeam Context must match Task.responsible

User must have at least one corresponding restriction category privilege in Task.restriction-category.

UserID must match Task.responsible, Task.owner or Task.requester


Patient

optional but when present:

must match Task.episodeOfCare

required when EOC context is not present:

must match Task.episodeOfCare.subject

UserID must match Task.responsible, Task.owner or Task.requester



System

-

-

-


...

Task search

User Type

EpisodeOfCare Context

Patient Context

CareTeam Context  / UserId

Extra Permission

Practitioner

optional but when present:

must match searchparam episodeOfCare

optional

must match searchparam ContextEpisodeOfCare.subject

Only checked if EOC context is not present:

CareTeam Context must match searchparam responsible

Users must have all restriction category privileges corresponding to the list in searchparam restriction-category.

UserID must match searchparam: Responsible, Owner or Requester

Patient

optional but when present:

must match searchparam episodeOfCare

required when EpisodeOfCare Context is not present:

must match searchparam theContextEpisodeOfCare.subject

UserID must match searchparam: Responsible, Owner or Requester

System

-

-

-

Draft of FUTURE change as a consequence of CCR0219: Task create/read/update

User Type

EpisodeOfCare Context

Patient Context

CareTeam Context  / UserId

Extra Permission

Practitioner

optional but when present:

must match Task.episodeOfCare

optional, but when present:

must match Task.episodeOfCare.subject

CareTeam Context must match Task.responsible

User must have at least one corresponding restriction category privilege in Task.restriction-category.

CareTeam Context must match one of Task.episodeOfCare.team (list)

UserID must match Task.responsible, Task.owner or Task.requester

(not checked when UserID match searchparam: Responsible, Owner or Requester)

Patient

optional but when present:

must match Task.episodeOfCare

required when EOC context is not present:

must match Task.episodeOfCare.subject

UserID must match Task.responsible, Task.owner or Task.requester

-

System

-

-

-

-

Draft of FUTURE change as a consequence of CCR0219: Task search

User Type

EpisodeOfCare Context

Patient Context

CareTeam Context  / UserId

Extra Permission

Practitioner

optional, but when present must match searchparam episodeOfCare

(Not checked as EOC context when present)

CareTeam Context must match searchparam responsible

Users must have all restriction category privileges corresponding to the list in searchparam restriction-category.

CareTeam Context must match one of Task.episodeOfCare.team (list)

UserID must match searchparam: Responsible, Owner or Requester

(not checked when UserID match searchparam: Responsible, Owner or Requester)

(not present)

Checked when EOC context is not present:
must match searchparam EpisodeOfCare.subject

CareTeam Context must match searchparam responsible

Users must have all restriction category privileges corresponding to the list in searchparam restriction-category.

CareTeam Context must match one of Task.episodeOfCare.team (list)

UserID must match searchparam: Responsible, Owner or Requester

(not checked if when UserID match searchparam: Responsible, Owner or Requester)

Patient

optional but when present:

must match searchparam episodeOfCare

required when EpisodeOfCare Context is not present:

must match searchparam EpisodeOfCare.subject

UserID must match searchparam: Responsible, Owner or Requester

-

System

-

-

-

-

When searching for tasks based on careteam, it is possible, but not necessary to specify restriction categories. If they are not specified as search criteria, then they will be inferred from the privileges in the security token.

...

Privately owned devices do not have context checks. The tables below are valid for devices owned by organizations.

Device/DeviceMetric create/update/delete

User Type

Organization Context

Patient Context

SSL supplier/Practitioner

required

must match the Device.owner organization

Optional but when present:

must match a DeviceUseStatement where:

  • DeviceUseStatement subject = patient context

  • DeviceUseStatement device references the device.


Patient

-

must match a DeviceUseStatement where:

  • DeviceUseStatement subject = patient context

  • DeviceUseStatement device references the device.

System

-


Device read

User Type

Patient Context

Organization Context

SSL supplier/Practitioner

Optional but when present:

must match a DeviceUseStatement where:

  • DeviceUseStatement subject = patient context

  • DeviceUseStatement device references the device.

Required if patient context is not present.

Must match the device.owner 

Patient

must match a DeviceUseStatement where:

  • DeviceUseStatement subject = patient context

  • DeviceUseStatement device references the device.

-

System


-

DeviceUseStatement create/update

User Type

Patient Context

Organization Context

SSL supplier/Practitioner

required

must match DeviceUseStatement.subject

required

must match the Device.owner organization

System

-

-

DeviceUseStatement read

User Type

Patient Context

Organization Context

SSL supplier/Practitioner

required

must match DeviceUseStatement.subject

-

Patient

must match a DeviceUseStatement.subject

-

System

-

-


Device/DeviceMetric/DeviceUseStatement - Work in Progress (will be in effect with next release)

Device/DeviceMetric create

User Type

Organization Context

Patient Context

SSL supplier/Practitioner

required

must match the Device.owner organization when the non-privately owned device

-

Patient (Must be privately owned device)

-

must match a DeviceUseStatement where:

  • DeviceUseStatement subject = patient context

  • DeviceUseStatement device references the device

or have no related DeviceUseStatement.

System

-

-

Device/DeviceMetric update/delete

User Type

Organization Context

Patient Context

SSL supplier/Practitioner

required

must match the Device.owner organization when the non-privately owned device

Optional but when present:

must match a DeviceUseStatement where:

  • DeviceUseStatement subject = patient context

  • DeviceUseStatematch device references the device.

or have no related DeviceUseStatement.

Patient

-

must match a DeviceUseStatement where:

  • DeviceUseStatement subject = patient context

  • DeviceUseStatement device references the device

or has no related DeviceUseStatement.

The device must be privately owned.

System

-

DeviceUseStatement create/update

User Type

Organization Context

Patient Context

SSL supplier/Practitioner

required

must match the Device.owner organization when the non-privately owned device

required

must match DeviceUseStatement.subject

Patient

-

required. The DeviceUseStatement must have:

  • DeviceUseStatement subject = patient context

  • DeviceUseStatement device references the device

The device must be privately owned.

System

-

DeviceUseStatement read

User Type

Organization Context

Patient Context

SSL supplier/Practitioner

-

required

must match DeviceUseStatement.subject

Patient

-

required

must match DeviceUseStatement.subject

System

-

-

DeviceUseStatement search

User Type

Organization Context

Patient Context

SSL supplier/Practitioner

-

required

patient search param must match the context

Patient

-

required

patient search param must match the context

System

-

-

Questionnaire

Questionnaire

User Type

FHIR Operation

Organization Context

Property updated

Role needed

Practitioner / Patient

create

required:

must match Questionnaire.modifierRole.reference

-

owner

update

required:

must match Questionnaire.modifierRole.reference

Questionnaire.modifierRole

owner

Not Questionnaire.modifierRole

owner or co-author

delete

required:

must match Questionnaire.modifierRole.reference

-

owner

read/search

-

-

-

System

-

-

-

-

Actionguidance

Actionguidance

User Type

FHIR Operation

Organization Context

Property updated

Role needed

Practitioner / Patient

create

required:

must match Actionguidance.modifierRole.reference

-

owner

update

required:

must match Actionguidance.modifierRole.reference

Actionguidance.modifierRole

owner

Not Actionguidance.modifierRole

owner or co-author

read/search

-

Note:

There are two ways to be able to search. First, if permission for both Actionguidance and view is present, it will give access.

Secondly, to search, an actionguidance permission should be present, and the resource should be supplied as part of the profile search or as the search field code. All other cases will be rejected.

 

Values to supply for a profile search

profile=http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-actionguidance

 

Values to supply for a code search

code=http://ehealth.sundhed.dk/cs/basic-resource-type|actionguidance

-

-

System

-

-

-

-

View

View

User Type

FHIR Operation

Organization Context

Property updated

Role needed

Practitioner / Patient

create

required:

must match View.modifierRole.reference

-

owner

update

required:

must match View.modifierRole.reference

View.modifierRole

owner

Not View.modifierRole

owner or co-author

read/search

-

Note:

There are two ways to be able to search. First, if permission for both View and view is present, it will give access.

Secondly, to search, a View permission should be present, and the resource should be supplied as part of the profile search or as the search field code. All other cases will be rejected.

 

Values to supply for a profile search

profile=http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-view

 

Values to supply for a code search

code=http://ehealth.sundhed.dk/cs/basic-resource-type|view

-

-

System

-

-

-

-

...

There are no context checks for CRUD and search operations for the Library resource.

Library evaluate

User Type

EpisodeOfCare Context

Patient Context

CareTeam Context

Practitioner

required:

must match either Observation.episodeOfCare

or QuestionnaireResponse.episodeOfCare

required:

must match either Observation.subject

or QuestionnaireResponse.subject

-

Patient

required:

must match either Observation.episodeOfCare

or QuestionnaireResponse.episodeOfCare

required:

must match either Observation.subject

or QuestionnaireResponse.subject

-

System

-

-

-

...

custom/findOrCreateParty

User Type

Organization Context

SSL supplier

required:
must match the organization parameter

Practitioner

required:
must match the organization parameter

System

-


Reports

Schedule/Fetch <Report_name>

User Type

Organization Context

UserID

Extra permission


Practitioner

required

Must match input parameter: ManagingOrganization

Only the user that called schedule is allowed to read the resulting /fhir/Binary/id

The privilege Report.non-anonymized is required if input parameter: anonymization == false


System-user

System users can't have an organization context

Only the user that called schedule is allowed to read the resulting /fhir/Binary/id

The privilege Report.non-anonymized is required if input parameter: anonymization == false


...

realm_access.role

Patient Context

Episode of Care Context

CareTeam Context

Organization Context

Extra Rules / Comments

Patient.read

R*


R*


REGULAR SEARCH:

To perform a regular Patient Search, the user MUST have the Patient Context.


LIMITED SEARCH (Dashboard Search):

It is also possible to perform a patient search witha CareTeam Context instead of a Patient Context. In that case, the patients are then retrieved from EpisodesOfCare and CarePlan objects that the CareTeam is involved in.

NOTE: The patient resources that are returned from this search are limited and as such only the following information is returned:

  • Identifier

  • Date of Birth

  • Gender

  • Cpr

  • Deceased status

  • Home address

  • Official name


*R - THE CONTEXTS ARE MUTUALLY EXCLUSIVE, AS SUCH IF BOTH CONTEXTS ARE PROVIDED IN THE TOKEN, ONLY THE PATIENT CONTEXT IS USED.

Patient.write

R




1: FHIR operations "create" and "update" are not available on the Patient resource. 
(use $createPatient and "patch")

2: Only certain attributes are allowed to be patched using HTTP PATCH

Patient$updatePatientWithSKRSData






Patient$createPatient






Appointment.read

U


U


For non-group appointments:

1: If an appointment involves a patient, then that patient must be in context

2: The appointment can be read if

  • the user has a Care Team in context that is participating in the appointment

  • the user is participating in the appointment (as a Practitioner or Patient)

3: Searching

  • PATIENT users can search all Appointments that involve the user itself

  • PRACTITIONER/SSL users can search all Appointments that involve the user itself, or the Organization/CareTeam/Patient in context

Appointment.write

U


U

For non-group appointments:

1: If an appointment involves a patient, then that patient must be in context

2: The appointment can be written if

  • the user has a Care Team in context that is participating in the appointment

  • the user is participating in the appointment (as a Practitioner or Patient)

Appointment$exportAsiCal

U

U

The same rules apply to reading appointments

Note: Only PRACTITIONER/SSL users can see the names of Practitioner participants in the exported iCal object

RelatedPerson.read

R




Only related persons to the patient in context can be read

RelatedPerson.write

R




Only related persons to the patient in context can be written

Communication.read



U


If the message has a restriction category X, the corresponding RestrictionCategory.X role must be present in the realm_access list.

1: PATIENT users can read

  • communication where they are either the sender or recipient

2: PRACTITIONER and SSL users can read 

  • communication where they are either the sender or recipient

  • communication where the CareTeam in context is the sender or recipient

3: Only SYSTEM users can read communication from DEVICE senders

Communication.write



U


1: Communication must have exactly one sender and one recipient

2: Communication with the category "note" can only be created/patched/deleted if user = sender and (recipient = sender or recipient = a CareTeam). 
(notes can be shared with any CareTeam)

3: PATIENT users 

  • can only create/delete "mesHTTP" communication where they are the sender, and the recipient is of type CareTeam

  • can only patch "message" communication where they are sender or recipient (the recipient can patch "received" property)

4: PRACTITIONER and SSL users 

  • can only create/delete "message" communication where the sender is the CareTeam in context and the recipient is of type PATIENT or type CareTeam

  • can only patch "message" communication where the CareTeam in context is the sender or recipient

Person$match





Only requires the role “Person$match”

Used to lookup person data by CPR, including name and a patient reference, if one exists.

This is only a read operation and will not create any resources.

The operations are audit logged.

...