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 + object_id
      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
9. Technically ABAC can take decision based on attributes of any entity. But to minimize load on the service it has been decided that we do restrict access not lower that on EPISODE level.
   1.  examples:
      1. access to endpoint like  `/api/patients/{patient_id}/conditions/{condition_id}` will be granted based on patient level rule
      2. access to endpoint like  `/api/patients/{patient_id}/conditions/` will be granted based on patient level rule
      3. access to endpoint like `/api/patients/{patient_id}/episodes/{episode_id}/encounters/` can be granted based on patient or episode level rule
      4. If there is a rule that allows user to get access to the patient level, but no rule that allows on the episode level, access should be allowed

Limitations

1. ABAC doesn't provide possibility to manage access to lists of resources - May be implemented in future
   
2. It means that if there is a business rule that '/api/patients/{patient_id}/conditions/' should return only conditions that are referenced to episodes of the legal_entity. This rule will not be implemented on ABAC.

Architecture

Data model - TBD

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

Permission definition language - TBD