Versions Compared

Key

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

...

Consent.create/read/patch

User Type

EpisodeOfCare Context

Patient context

CareTeam Context

Practitioner

Required

Must match data.reference

Required

Must match data.patient

-

Patient

Required

Must match data.reference

Required

Must match data.patient

-

System

-

-

-


Consent.search

User Type

EpisodeOfCare Context

CareTeam Context

Practitioner

required:

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

-

Patient

required:

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

-

System

-

-

CarePlan/ServiceRequest

ServiceRequest is considered a part of a CarePlan and does not have separate privileges.

CarePlan cannot be created directly. It is created and assigned to a Patient by calling PlanDefinition$apply 

CarePlan/ServiceRequest Read/Suggest-care-teams

User Type

EpisodeOfCare Context

CareTeam Context


Practitioner

required:

must match CarePlan/ServiceRequest .episodeOfCare

required:

Careplan: Context must match CarePlan.careTeam or Careplan.episodeOfCare.team

ServiceRequest: Context must match CarePlan.careTeam or Careplan.episodeOfCare.team for the CarePlan that the ServiceRequest belongs to.

Patient

required:

must match CarePlan/ServiceRequest.episodeOfCare


-

System

-

-


CarePlan/ServiceRequest Update/Update-care-teams

User Type

EpisodeOfCare Context

CareTeam Context

Extra permission


Practitioner

required:

must match CarePlan/ServiceRequest.episodeOfCare

required:

Careplan: Context must match CarePlan.careTeam or CarePlan.episodeOfCare.team

ServiceRequest: Context must match CarePlan.careTeam or CarePlan.episodeOfCare.team for the CarePlan that the ServiceRequest belongs to.





Patient

required:

must match CarePlan/ServiceRequest.episodeOfCare

-

Only allowed if definition.topic is 'self-treatment' 



System

-

-



...

Draft of FUTURE change as a consequence of CCR154: CommunicationRequest Search

User Type

EpisodeOfCare Context

Patient Context

CareTeam Context

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

-

-

-

ClinicalImpression/Task

ClinicalImpression create/read/update

User Type

EpisodeOfCare Context

Patient Context

CareTeam Context


Practitioner

required:

must match ClinicalImpression.episodeOfCare

required:

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

must match ClinicalImpression.subject

-



System

-

-

-



ClinicalImpression.search

User Type

EpisodeOfCare Context

Patient Context

CareTeam Context


Practitioner

optional but when present:

must match searchparam: episodeOfCare

optional

must match searchparam: subject

Only checked if EOC context is not present:

required:

Must match search param value in context.team or carePlan.careTeam


Patient

optional but when present:

must match searchparam: episodeOfCare

required when EpisodeOfCare Context is not present:

must match searchparam: subject


-



System

-

-

-



Task create/read/update

User Type

EpisodeOfCare Context

Patient Context

CareTeam Context  / UserId

Extra Permission

Practitioner

optional but when present:

must match Task.episodeOfCare

optional, but when present:

must match Task.episis odeOfCare.subject

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

must match Task.episodeOfCare.subject

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



System

-

-

-



Task search

User Type

EpisodeOfCare Context

Patient Context

CareTeam Context  / UserId

Extra Permission

Practitioner

optional but when present:

must match searchparam episodeOfCare

optional

must match searchparam Context.subject

Only checked if EOC context is not present:

CareTeam Context must match searchparam responsible

Users must have all restriction category privileges corresponding to the list in searchparam restriction-category.

UserID must match searchparam: Responsible, Owner or Requester

Patient

optional but when present:

must match searchparam episodeOfCare

required when EpisodeOfCare Context is not present:

must match searchparam theContext.subject

UserID must match searchparam: Responsible, Owner or Requester

System

-

-

-

When searching for tasks based on careteam, it is possible, but not necessary to specify restriction categories. If they are not specified as search criteria, then they will be inferred from the privileges in the security token.

...

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.

...