Page Comparison

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.