Page Comparison

realm_access

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

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.

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"

PlanDefinition$apply

Practitioner

required:

Must match EpisodeOfCare.id

required:

Must match EpisodeOfCare.team

System

-

-

DocumentReference.read/search

Practitioner / Patient

-

System

-

DocumentReference.create/update

Practitioner / Patient

required:

must match DocumentReference.custodian

System

-

Consent.search

Practitioner

required:

must match the EpisodeOfCare search parameter (consent.data.reference)

-

Patient

required:

must match the EpisodeOfCare search parameter (consent.data.reference)

-

System

-

-

CommunicationRequest Search

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 Search

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

-

-

-

DeviceUseStatement read

SSL supplier/Practitioner

required

must match DeviceUseStatement.subject

-

Patient

must match a DeviceUseStatement.subject

-

System

-

-

View

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

-

-

-

-

Library evaluate

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

-

-

-

Schedule/Fetch <Report_name>

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

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.