Versions Compared

Key

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

...

Device/DeviceMetric update/delete

User Type

Organization Context

Patient Context

SSL supplier/Practitioner

required

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

Optional but when present:

must match a DeviceUseStatement where:

  • DeviceUseStatement subject = patient context

  • DeviceUseStatement 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 have no related DeviceUseStatement.

Device must be privately owned.

System

-

Device/DeviceMetric read

User Type

Organization Context

Patient Context

SSL supplier/Practitioner

required

must match device.owner if patient context is not present and device is non-privately owned

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.

or have no related DeviceUseStatement.

System

-

...

realm_access.role

Patient Context

Episode of Care Context

CareTeam Context

Organization Context

Extra Rules / Comments

Patient.read

R*


R*


REGULAR SEARCH:

In order to perform 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 involves the user itself

  • PRACTITIONER/SSL users can search all Appointments that involves 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

Same rules apply as for 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 corrosponding RestrictionCategory.X role must be present in the realm_access list.

1: PATIENT users can read

  • communication where they themselves are either the sender or recipient

2: PRACTITIONER and SSL users can read 

  • communication where they themselves 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 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 "message" communication where they are sender and recipient is of type CareTeam

  • can only patch "message" communication where they are sender or recipient (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 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






...