Content Comparison

...

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. Anchor
      Future Future

      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

...