## 5 Example  
### The Basic Configuration and Its Implementation  
As an example, we consider a very small health system. In generic terms, its configuration is as follows: there are _sensors_ for patients' blood pressure and pulse. There are _wards_, each of which has _doctors_ and _murses_, and patients are assigned to wards. There is also a _Reanimation_ department and a _Chief of Medicine_ department, each with a workstation. Entities other than sensors are application entities. There are the following data categories: _Pressure_ and _Pulse_ data for each patient, and _Stat_ (statistics) data for each ward. The security policies or requirements to be implemented are as follows:  
* The sensors should have the highest integrity but also low secrecy since their _Pressure_ and _Pulse_ data are needed by all other entities. Thus, they must be at the bottom of the partial order [20], and this is where they will end up given that their labels contain only one data category. * The _Chief of Medicine_ department will have the lowest integrity since it uses data collected from all other entities, but also the highest secrecy, since it contains highly sensitive data for all patients and _Wards_. It must be at the top of the partial order [20], and this is where it will end up given that its label contains all data categories. * The _Wards_ and _Reanimation_ departments take data from the _sensors_, process them, and forward the results to the _Chief of Medicine_ department, they should have intermediate levels of integrity and secrecy. * Conflicts: (a) Patient data should be known only in each patient's own _Ward_ and in the _Reanimation_ and the _Chief of Medicine_ departments. In addition, (b) Each _Ward_ keeps its own statistics that should be known only to it and to the _Chief of Medicine_. These conflicts are represented by forbidding labels containing conflicting data categories, such as, in our example, _[PERSON]_ in _Ward2_. We limit ourselves to an instance of this type of network where there are two _Wards_ and three patients, _[PERSON]_, _[PERSON]_, and _[PERSON]_, each using a sensor. It is shown in Figure 3. In the figure, rectangles represent _sensors_ (three in the bottom layer) or _application entities_ (six in the layers above) and include an upper-case letter for a short name of the entity, a longer descriptive name, and the label (a set of data categories) in braces. For readability, labels  
Figure 2: Summary of our method. have been simplified with respect to the theory presented in Section 2, but still show the data categories allowed in each entity, e.g., the workstation of _Doctor2_ can contain the data for Sally and some local statistics. As in Section 3, arrows represent directional channels for receiving (reading, pulling) and sending (writing, pushing), so for example in Figure 2 entity C can send data to \(K\), or equivalently \(K\) can receive data from \(C\). There is an arrow, or a path of arrows (a data flow), between an entity and another iff the label of the first entity is included in the one of the second. According to IoT terminology, the three sensors are the _Sensing layer_ and the rest is the _Application layer_. Figure 3 shows a 'direct' _Channel_ configuration without the _Cloud_ or the _Networking layer_. It can be checked that the security policies above are implemented by the choice of label sets, which was done by the security administrator at the time the network was configured, explicitly or implicitly by defining the _Channel_ relation. For example, the blood pressure of _[PERSON]_ can only be known in _Ward1_, in the _Reanimation_ or _Chief of Medicine_ departments. Figure 3 represents the network architecture that results from the data flow policies. The resulting partial order of equivalence classes in this architecture is shown in Figure 4, using letters for the names of the entities in Figure 3. Note the non-trivial equivalence classes {_A,C_} and {_B,D_}, since the entities in Wards have symmetric channels and thus can know the same data.