...
What operations that the user is allowed to do is stated in the "realm_access" attribute. In the example above the user is allowed to issue a "Patient.read" and a "Patient.write". This means that the user can get and edit patient records. This part of the security model is the RBAC part, as the claims here are entirely based on what role the user has. Each resource type (see https://docs.ehealth.sundhed.dk/latest/igfhir/profiles.html) has certain restrictions to what context must be issued, to allow data retrieval or data manipulation. This is stated in the Access rights section below (For instance, to either read/search or write to a patient, the patient must be in context). Furthermore, the context attribute shows what data is in context. The set of items that can be set into context are Organization, Patient, CareTeam, and EpisodeOfCare (see Switching Context). As such, the eHealth Infrastructure governs the access to data using both RBAC (stated roles from login) and ABAC (asserting data attributes on the actual content).
...
The current list of privilege roles defined is given in the table below.
OIO BPP Role Role to eHealth Privilege mapping lists all the privileges for each role.
...