Table of Contents |
---|
...
Draft of FUTURE change as a consequence of CCR154: CommunicationRequest Search | ||||
User Type | EpisodeOfCare Context | Patient Context | CareTeam Context | |
---|---|---|---|---|
Practitioner | Required if searchparam episodeOfCare is specified. In this case 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:
| optional but when present: must match searchparam CommunicationRequest.subject | required if 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 | - | - | - |
...
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:
*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. 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
3: Searching
| ||
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
| ||
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
2: PRACTITIONER and SSL users can read
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). 3: PATIENT users
4: PRACTITIONER and SSL users
| |||
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 is audit logged. |
...