Versions Compared

Old Version 43

changes.mady.by.user Andreas Harfeld Jakobsen

Saved on

compared with

New Version 44

changes.mady.by.user malthe lange

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

...

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. 

...

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.

...