Page Comparison

Condition

Practitioner

required:

must match Condition.episodeOfCare

required:

must match Condition.subject

-

Patient

required:

must match Condition.episodeOfCare

required:

must match Condition.subject

-

System

-

-

-

Consent.create/read/patch

Practitioner

Required

Must match data.reference

Required

Must match data.patient

-

Patient

Required

Must match data.reference

Required

Must match data.patient

-

System

-

-

-

Goal Create/Read/Update

Practitioner-

required:

Must match Goal.subject

required:

must match Goal.addresses.episodeOfCare

required:

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

Patient

required:

Must match Goal.subject

-

-

System

-

-

-

CommunicationRequest Create/Read/Update/Delete

Practitioner

required

must match CommunicationRequest.episodeOfCare

not checkedrequired

must match CommunicationRequest.recipient

required

must match CommunicationRequest.recipient if recipient contains a careteam

Patient

optional but when present:

must match CommunicationRequest.episodeOfCare

required

must match CommunicationRequest.recipient

-

Update: Only status

System

-

-

ClinicalImpression create/read/update

Practitioner

required:

must match ClinicalImpression.episodeOfCare-

required:

must be in ClinicalImpressions.match ClinicalImpression.subject

required:

must be in ClinicalImpressions.ehealth-careplan.careTeam or ClinicalImpressions.episodeOfCare.team

Patient

optional but when present:

must match ClinicalImpression.episodeOfCare

required when EOC context not present:

must match ClinicalImpression.subject

-

System

-

-

-

Task create/read/update

Practitioner

optional but when present:

must match Task.episodeOfCare

optional, but when present:

must match Task.episodeOfCare.subjectOnly checked if EOC context is not present:

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 not present:

must match Task.episodeOfCare.subject

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

System

-

-

-

Communication create/patch

Practitioner

optional but when present:

must match communication.episodeOfCare

required if EpisodeOfCare context not present:

must match communication.subjectOnly checked if EpisodeOfCare Context is not present.

A match must be found either through the Careteam or the UserID

• Careteam: must match either communication.senderCareTeam

• UserID: must match communication.sender

Patient

-

required:

must match communication.subject

-

communication.sender must match AuthToken.userId

System

-

-

-

QuestionnaireResponse read

Practitioner

required:

must match questionnaireResponse.episodeOfCare

--

required:

If the CareTeam is assigned on the EpisodeOfCare:

• The user is granted access with no further checks when the EpisodeOfCare.team of the EpisodeOfCare Context contains the CareTeam in the CareTeam Context

If the Careteam is assigned on the CarePlan:

• QuestionnaireResponse.basedOn must be a ServiceRequest which is referenced in CarePlan.activity.reference where the CarePlan.careTeam contains the CareTeam in the CareTeam Context

Patient

optional but when present:

must match questionnaireResponse.episodeOfCare

required when EOC context not present:

must match questionnaireResponse.subject

--

System

--

--

--

$submit-measurement

Practitioner

required

required

Patient

required

required

System

--

--

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