## 3 A Motivating Use Case for Healthcare  
In healthcare systems, authorization is put in place to manage access control to sensitive data, such as a patient's medical records or data collected by mobile health trackers. However, medical processes are often represented as workflows involving multiple stakeholders. As a result, authorization too involves complex procedures (e.g., patient consent, approval delegation of authority, break-the-glass, audit access logs, need-to-know), and these procedures are not easily implemented as a set of access rules. For example, rather than just evaluating a rule to verify whether a patient has given consent in the past, the authorization system may explicitly ask the patient for consent. In this case, patient consent can be implemented as a task in an authorization workflow. However, in emergency situations, patient consent may be implicit as a result of a break-the-glass procedure, again a task where a healthcare professional (i.e., the subject) can override access to read (i.e., the action) the patient's medical data (i.e., the resource) under the condition that he/she motivates why he/she triggered the break-the-glass procedure. Last but not least, the need-to-know principle states that even if a healthcare professional has the necessary approvals (such as patient consent), the subject should not be given access to medical data unless there is a specific need (so not only who and what, but also why) in order to avoid healthcare data exposure due to insider attacks. If a patient is enrolled in a consultation, he/she is part of a workflow, and only the medical actors involved in the same workflow may be granted access to (a subset of) that patient's data. As a result, the execution of the main medical workflow may be subject to the execution of a co-existing authorization workflow. Furthermore, certain subjects (e.g., trainees) may be prohibited from executing a break-the-glass authorization procedure. All these examples illustrate that externalizing access control in workflow-oriented applications is challenging. Figure 5 provides a simplified overview, identifying the stakeholders, the data being collected and processed and the processes in place. Note that these services can be hosted by different online service providers, each with their own access control solutions. For example, the Mobile Health Tracker platform that collects and processes fitness and health data, may be hosted in the cloud by the company that sells the wearables. Similarly, the Patient Appointment scheduling system may be offered online as a multi-tenant cloud service with multiple doctor's offices as clients. The data being managed by the general practitioners themselves are the medical records and the user enrollment of the members of the doctor's office (e.g., physicians, trainees, dietists, secretaries, etc.). Figure 5: Authorization as a workflow in a healthcare context. Here are some non-trivial access control use cases that cross-cut the different services. We will use them later on to illustrate our workflow-oriented authorization of microservices with feature toggles and circuit breakers:  
1. After patient consent, the Medical Records system receives summaries of aggregated healthcare results of the Mobile Health Tracker platform, as well as detailed information (time, location, health parameters) when certain (aggregated) health parameters are above or below critical thresholds (e.g., heart rates, blood glucose values, etc.) defined by the physician. The latter should not be able to retrieve all data simply by changing the thresholds. 2. A physician should have a specific need to access sensitive data, even if he/she has the necessary consent and permissions. This need-to-know concern is reflected by the presence of a future patient appointment. However, the physician should not be able to override access simply by creating a patient appointment. The appointment should either be scheduled by the patient himself/herself or otherwise be approved by the patient.