## 7 Networks with Multiple Data Flows  
In the example of Section 5, we have only considered the existence of a single data flow in the network. Usually, however, several separate data flows are present in networks. Each one of these flows will have different security requirements and will need to be controlled separately, hence it will have its partial order. We modify our hospital example to add a downward flow that we call _Diagnostic_, from the _Chief of medicine_ towards the patients. For this new flow, the secrecy-integrity requirements are reversed, and labels denoting combinations of patients' diagnostic data are allowed only for certain equivalence classes of entities. We say that the example of Section 5 deals with _Consultation_ data that flow from patients towards the medical staff as we have seen. We add to this _Diagnostic_ data that travel in the opposite direction and have their requirements in terms of secrecy, which leads to a different partial order. The network with the representation of the two different flows is shown in Figure 11. In this figure, it is possible to find all flows considered in Section 5, plus the new ones, among others the flow \(K{\rightarrow}D{\rightarrow}E\) by which _[PERSON]_ receives her medical results. We have two sets of labels, one with the flow identifier _Consultation_, and the other with the flow identifier _Diagnostic_. There are also some new entities: _BobWkstn_, _SamWkstn_, and _SallyWkstn_ respectively \(L\), \(F\), and \(E\), which represent the patient applications that will allow them to consult the _Diagnostic_ data flow. So some entities will have two labels. For example, the labels of _ChiefMedicWkstn_ are as follows: _Consultation_ (_SamPress, BobPulse, SallyPulse, Stat1, S tat2_) and _Diagnostic_ (_SamDiagnos, SallyDiagnos, BobDiagnos_). This means that _ChiefMedicWkstn_ participates in the two flows, and that for each flow, _ChiefMedicWkstn_ has access to data on the corresponding labels. This example shows an application of the concept of _trusted entities_ that can access data belonging to different flows but are trusted to deliver the right data to the rightful entities only. One such entity is the _ChiefMedicWkstn_. This entity knows both _[PERSON]'s_ and _[PERSON]'s_ data and sends data to both, but it is expected not to send _[PERSON]'s_ data to _[PERSON]_ or vice-versa. The concept of a trusted entity is well established in security theory and is present in the _Bell-La Padula model_[19], where trusted subjects are described as \"guaranteed not to consummate a security-breaching information transfer even if it is possible\". Trusted entities are very common in security; for example, a bank employer will hold separate in her mind the two conversations she may be having with her manager and with her client on two different phone lines. Trusted entities can be thought of as split into different parts, one for each flow to which they belong, with controlled internal communication between the parts. Each part will be governed by the label associated with its flow. In the example below, the Chief Medical Workstation and its database (\(K\), \(K^{\prime}\)) are trusted entities that are supposed to keep separate the data of the three users, and similarly, the doctor and nurse workstations and databases (\(C\), \(A\), \(A^{\prime}\)) are supposed to keep separate the data of _[PERSON]_ and _[PERSON]_. This could be shown in greater detail but at the cost of complicating the presentation. In order to implement this model, we need to create a network where all the data are saved in the Cloud. For this purpose, we add storage entities to the newly created entities for the patients. These can be small storage spaces allocated through the patient's account created during registration on the hospital servers. Figure 12 represents the resulting network. We have two sets of labels, one set for each flow, respectively, named _Consultation_ and _Diagnostic_. For each flow, the labels associated with that flow are used.