There are a number of use cases when user should be granted with access to some resources (episode, encounter, etc.) based on different business rules.

JUST examples:

• User can read the complete patient medical data in case if it's employee has active declaration with the patient
• User can read some part of medical data in case if it's legal entity has declaration with the patient
• User can read episode details, in case if referral linked with the episode has been assigned to user,
• etc. 

That's why ABAC (Attribute-based access control) paradigm should be used to control access to the medical data resources on the top of the scope model.

Medical events Access policy can be found here

General Concept design

1. ABAC is an independent microservice
2. It is responsible for granting access to resources based on attributes of any business entity that are requesting access for.
3. Service will not support UI editing of rules
4. Service should provide RPC (or similar as service must not spend additional computation time on decoding/encoding and networking)
5. Service must store audit log in files with two main events: "Successful access grants", "Access rejects".
6. Service must cache data for resources, with cache lifetime on per resource sets
7. ABAC is additional level of authorization on the top of the regular scope-based access model.

Usage

1. ABAC might (NOT MUST) be used as a plug for any ME endpoint or even ehealth endpoint. Otherwise there might be performance issues.
2. It should be checked on the gateway level.
3. We do limit access by default. It means that all the rules describe conditions when access is allowed. If there is no rule matched - access is forbidden.
4. If ABAC failed to answer - access is forbidden.
5. ABAC - mission critical service
6. Interface: external: http, data providers: RPC
7. Input:
   1. WHO
      1. user_id
      2. client_id + client_type
         
   2. action: CREATE, READ, UPDATE, DELETE
   3. WHAT
      
      1.  object_type(resource) + object_id(optional)
      2. list of contexts (patient, episode):
         1. object_type + object_id
8. Output:
   1. decision: true/false
   2. To be considered in future!! Conditions - optional. Is relevant for lists. Defines additional instructions for the requested application.
      1. For example: client_id context should be applied
      2. For example: speciality context should be applied

Limitations

1. When accessing list of entities, ABAC can only grant access to the whole list or forbid the whole list. ABAC does not cut the response in order to show only entities allowed by the rules.
2. When accessing list of entities, only one rule could be applied. That means ALL entities from the requested list should be allowed by that one rule. To achieve this, search parameters are used as context. For example, to read episodes, created in the doctor's MSP, doctor can request list of episodes, filtered by managing_organization_id. Managing organization, in this case, will be considered as a context and validated by corresponding rules. If one of the rule returns true, user can access the requested list. This way each entity from the list wasn`t validated by each rule separately, that significantly saves computing time.

Architecture

Data model

https://docs.google.com/spreadsheets/d/1A59VIXzxJGLxdd6XH2siPQqOcgVfkGy-1mpR7_4vK4Y/edit#gid=0

Permission definition language - TBD

Rules