Use of context-based adaptation to defuse threatening situations in times of a pandemic

1.1 Motivation

At the end of 2019, an increasing number of people in Wuhan (China) were diagnosed with pneumonia, the cause of which could be traced back to a previously unknown coronavirus. ⁵ Initially referred to as 2019-nCoV, this pathogen soon became known as Severe Acute Respiratory Syndrome Coronavirus Type 2 (SARS-COV-2) around the world ⁶ and is the cause of the infectious disease known as Coronavirus Disease 2019 (COVID-19). Due to the rapid increase in the number of infections ⁷ and the spread of the pathogen throughout the world, the secretary-general of the World Health Organization (WHO) officially declared the outbreak of COVID-19 as a pandemic on March 11, 2020. ⁸ By the beginning of 2024, more than 773 million people worldwide have been infected with SARS-COV-2 and more than 7 million people have died from COVID-19 or its consequences. ⁹

In order to bring the COVID-19 pandemic under control, various regulatory measures have been applied worldwide to keep infection chains as short as possible to make the transmission of SARS-COV-2 more difficult. In addition, the fight against the COVID-19 pandemic was also supported by technology. For the first time in human history, various approaches have been developed that are summarized under the term digital contact tracing in the literature. The aim of such approaches is to automate the tracing of close contacts with infected people in order to be able to identify close contacts that have taken place without the need for high personnel resources. This should enable systematic contact tracing, even if a pathogen spreads quickly. ^{10 , 11 , 12} To achieve this goal, a person’s smartphone is used to record data about encounters with other people and share this information in case the person is infected, so that the people encountered can be warned about a contact with them. ¹¹ Although some individual approaches differ significantly in their architecture, the currently known solutions essentially estimate the distance between people and record the duration of encounters in order to be able to use this data to infer close contacts in the event of a confirmed infection. ¹⁰ The distance estimation is primarily done via Bluetooth Low Energy (BLE), ¹¹ as it enables more accurate contact tracing indoors compared to Global Positioning System (GPS) or Wireless Local Area Network (WLAN) and is also available on most of the smartphones used today. ^{13 , 14}

1.2 Problem

Although promising, digital contact tracing has not been able to effectively contain the spread of SARS-COV-2. One of the reasons for this is seen in the lack of acceptance among the population in many countries. ¹¹ In addition to that, there are also publications that question the practicability of digital contact tracing based on BLE. In Ref. 15], for example, it is argued that a high degree of precision in distance estimation is required for useful contact tracing because epidemiological guidelines often require that a distance between two people must be less than a few meters in order to be able to assume close contacts at all. ^{16 , 17 , 18} Thus, deviations in the range of meters are not tolerable. With this in mind, BLE cannot achieve the required precision. Various papers have shown experimentally that deviations in the range of a few meters have to be expected when estimating distances via BLE. ^{14 , 19 , 20}

Besides the precision, digital contact tracing also has the disadvantage that it does not sufficiently take the context of an encounter into account since it essentially uses the distance and the duration of an encounter to infer a close encounter. The context can be understood as a set of background information that can be helpful for understanding a situation. It plays an important role in the subsequent assessment of whether an encounter carries the risk of an infection and, as a result, is to be classified as a close contact. The Robert Koch-Institut (RKI), for example, clarifies that in order for an encounter between two people to be considered as a close contact, there must be a breach of distance without adequate protection. ¹⁷ Nevertheless, the principal disadvantage of digital contact tracing is that it is retrospective. For contact tracing to be effective, a close contact must have been occurred.

1.3 Objectives

In this paper, the fight against the spread of infectious diseases is considered from an alternative perspective, which is based on the following observation. The transmission of an infectious disease is contingent upon the presence of a threatening situation that may result in infection. Consequently, the likelihood of an individual falling ill is contingent upon the timely recognition and defusing of such a situation by applying protection measures. It can be posited that a forward-looking approach to infection prevention may prove more efficacious than a backward-looking contact tracing. An information system designed to support infection prevention must be able to assist a person in recognizing and defusing threatening situations. To do this, the system must be able to determine the person’s context, evaluate it with regard to the risk of infection and the person’s possible illness, and suggest adequate protection measures. In general, systems that can adapt their behavior depending on a context are referred to as context-sensitive systems and the adaptation process they use is called context-based adaptation. ²¹ Therefore, a system to support infection prevention is to be classified as a context-sensitive system. In this paper, a novel approach for such a digital infection prevention system is presented.

The remainder of this paper is organized as follows: The Sections 2–4 provide the essential foundation for understanding of the rest of the paper. In Section 5 the requirements to be met are identified. Section 6 describes the related work identified in the literature. Section 7 deals with the question of how the requirements can be met and presents a concept for a digital infection prevention. Section 8 then addresses the validation of the concept. Finally, Section 9 concludes this paper by summarizing the central results and suggesting further research.

3.1 Sensors

Sensors are needed to digitally capture a person’s situation. They pick up signals from the person’s environment, process them and generate data that can be used to describe what is happening in a situation. The following definition is therefore made:

Sensors can generate data on different semantic levels. A proximity sensor, for example, can output a distance or a classification of a distance. The question therefore is, on which semantic level the data generated by sensors must be located. In this paper, no restrictions are made in this regard and it will be discussed later how such differences can be taken into account.

3.2 Protection measures

Protection measures describe how threatening situations can be defused. The prerequisite for the emergence of such a situation is the risk of an infection if it can cause illness (see Definition 3.2). As described in Section 2 there are two types of measures when it comes down to protection against infectious diseases. They either address the contact with a pathogen or the outbreak of the corresponding disease, but neglect the fact that protection can also be achieved if a pathogen has been transmitted to the human body but is then prevented from penetrating it. Accordingly, the following definition is made:

4.1 Notion of context

The concept of context has its origins in linguistics, where it refers to all aspects of a communication situation that influence the understanding of an utterance. ²⁴ A similar understanding can also be found in social sciences and humanities, where context describes a framing with background information that is helpful for understanding something that is the focus of interest. ^{25 , 26 , 27}

In computer science, the notion of context has its origins in the field of ubiquitous computing. In Ref. 28] it is argued that a constantly changing execution environment is an important aspect of which applications must be aware of in order to be able to react specifically to a changing environment. Therefore, context is defined there as “[…] where you are, who you are with, and what resources are nearby” 28], p. 85. Afterwards this definition is illustrated by an enumeration of some exemplary factors. However, due to the exemplary list, it is justifiably criticized in Ref. 23] where another definition is proposed for context:

[…] any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves. 23], pp. 306–307

Although this definition is more general, it does not specify whether an information must also be relevant for a specific objective. Therefore, context is defined as follows in this paper:

The relationship between a context and a situation is illustrated in Figure 2. A person is in a current situation (white rectangle) and is surrounded by events that are described by information (circles). The situation itself follows on previous situations (gray rectangles). The person was also surrounded by events in these situations. Regardless of where a piece of information has its temporal origin, all information that could be relevant in the current situation belong to the person’s context (gray circles). This includes not only information about current events but also information about previous events.

Figure 2:

Relationship between a situation and a context.

4.2 Modeling of context

When it comes down to modeling context, ontology-based models have proven themselves in comparison to other approaches. ²⁹ In computer science, an ontology is a formal specification of knowledge for a specific domain. It defines the relevant vocabulary, which consists of classes, relations, functions and axioms. An ontology thus describes a section of the real world by defining the concepts relevant to the section, their properties, the relationships between them and the applicable axioms. ^{30 , 31 , 32 , 33} An established language for describing ontologies is Web Ontology Language (OWL), which is now available in version 2 and is standardized by the World Wide Web Consortium (W3C). ^{34 , 35} OWL has many parallels to object-oriented languages and consists of the following fundamental elements: ³⁶

1. Classes: Classes describe sets of individuals. They are therefore abstract concepts and represent classes of objects in the same way as object-oriented languages.

2. Individuals: Individuals are concrete instances of classes. In contrast to many common object-orientated languages, however, ontologies allow individuals to belong to several classes at the same time.

3. Literals: Literals are data values such as strings or integers.

4. Object properties: Object properties describe relationships between individuals. They therefore represent the object relationships known from object-oriented languages, in which an object refers to another object.

5. Data properties: Data properties describe relationships between individuals and literals. They therefore represent the attributes of objects known from object-oriented languages.

In OWL all elements are identified by Internationalized Resource Identifiers (IRIs), which are a generalisation of the Uniform Resource Identifiers (URIs). ³⁷ The elements of an ontology can be addressed by IRIs, in particular different ontologies can also refer to each other.

4.3 Determination and utilization of context

In Ref. 21] a generic and domain-independent framework for determining and using context is presented under the name Generic Context Framework (GCF) (see Figure 3). The GCF describes various aspects of context-based adaptation and structures them in four layers:

1. Knowledge Layer: The knowledge layer forms the basis of the GCF and provides the layers above it with a standardized and situation-independent Domain Model in which all relevant concepts of a domain are specified. Both the existing prior knowledge and existing Inference Rules are transferred into the model. While prior knowledge refers to all concepts to be included in the model, Inference Rules describe how concepts or relationships between them can be derived on the basis of the Domain Model. Prior knowledge can further be divided into abstract and concrete prior knowledge. While Abstract Predefined Knowledge includes information about classes of individuals as well as information about relationships between the classes, Concrete Predefined Knowledge contains information that only concerns specific individuals.

2. State Layer: In comparison to the knowledge layer, the state layer contains information about an ongoing situation that is merged into a current State. Sensing Rules are used to generate and update the State. They receive data generated by sensors and instantiate the Domain Model provided by the knowledge layer. At this point, it can now be explained how the possible semantic differences in the data, which could originate from different sensors (see Section 3.1) can be taken into account. The semantic differences are intercepted by the Sensing Rules as they map the input data to the standardized Domain Model. By integrating the sensor data into a State, there is also a decoupling from the current situation, which makes it possible to record both information about the current situation and information about previous situations in the State.

3. Context Layer: In the context layer, a slice of the current state is determined depending on a specific focus and stored as the context. The focus is a non-empty set of objects of the state that represent the current center of attention. The context is determined with the help of Contextualization Strategies, which, in addition to the pure selection of objects from the state, can also entail their interpretation and abstraction based on the Domain Model. This allows both the complexity and the size of the context to be reduced compared to the underlying state. As a result, the context includes the focus itself as well as all other information that could be relevant for the focus according to the Contextualization Strategies.

4. Adaptation Layer: On the basis of the determined context, adaptation rules that should be applied are selected in the adaptation layer. Adaptation Rules specify the necessary conditions that must be met for their selection and application and also indicate the adaptations that should be made to a system. The result of their application is the Adapted State, which can be understood as the subsequent state of the current state (see state layer).

Figure 3:

A four-layered framework for context-based adaptation–generic context framework based on Ref. 21].

The descriptions above already indicate the adaptation cycle that underlies the GCF and enables context-based adaptation. The knowledge layer provides the layers above it with a uniform conceptual basis. The state layer maintains a current State that contains information about both a current situation and previous situations. As a result, the State includes information about the events of a current situation as well as information about events that occurred earlier. This makes the State useful for determining the context in the context layer. There, the scope and complexity of the State are reduced to the currently relevant information by performing a selection and abstraction using Contextualization Strategies. The result is the context on the basis of which a selection of Adaptation Rules is made. After their application (or new sensor data), a subsequent State emerges and the cycle restarts.

5.1 Recognizing threatening situations

In order for the person being supported to be able to apply protection measures and defuse a threatening situation, the person must become aware of such a situation.

1. It must be possible to alert the person being supported to a situation that is threatening for them.

The threat posed by a situation is influenced by protection measures that the person being supported has already applied. For example, an infection with SARS-COV-2 can be prevented, if the person is properly wearing a medical face mask.

1. The recognition and defusing of a threatening situation should be possible depending on the protection measures applied by the person being supported.

While protection measures can reduce the threat of a situation, the person’s pre-existing diseases can increase the threat of a situation.

1. The recognition and defusing of a threatening situation should be possible depending on the pre-existing diseases of the person being supported.

Whether a situation poses a threat also depends on the pathogen in relation to which the threat level should be assessed.

1. The recognition and defusing of a threatening situation should be possible depending on a pathogen.

As described in Section 3, a threatening situation can only arise if the person being supported is in a situation in which an infection can occur. In this regard a distinction must be made between different transmission paths (see Section 2). While a direct transmission path refers to a human-to-human transmission, an indirect transmission path refers to a vehicle-to-human or a vector-to-human transmission.

5.2 Defusing threatening situations

The protection measures that can be applied to defuse a threatening situation always depend on a pathogen. Also, in some circumstances, several protection measures may be possible. The person being supported should therefore be supported in dealing with a threatening situation.

1. The person being supported should be supported in dealing with a threatening situation depending on a pathogen.

7.1 Architecture

The central elements of the infection prevention are shown in Figure 4. The approach encompasses an app that is referred to as InfectPreventionApp in the following. In the approach a person must use the app in order to get supported in detecting and defusing threatening situations. Each person being supported (person symbol in Figure 4) requires its own instance of the app. It is assumed that a person being supported has a portable, individual device with BLE support (e.g. a smartphone) on which the app can be executed.

Figure 4:

Architecture of the infection prevention.

The InfectPreventionApp periodically broadcasts a signal via BLE to inform nearby entities (cloud symbol in Figure 4) that are involved in the infection prevention about its presence. It is assumed that these entities also broadcast a signal via BLE so that the InfectPreventionApp can also detect their presence.

The app uses Sensors to capture the situation of the person being supported. Once the situation has been captured, it must be evaluated in regard to its threat level. The specific approach and the protection measures that should be suggested afterwards depend on a pathogen. According to the requirement R6, the app therefore needs specifications that allow it to identify what information has to be evaluated and how and what protection measures should be suggested to the person being supported. Such specifications are recorded in Prevention Profiles. The approach presented here envisages that Prevention Profiles are provided by profile creators (building symbol in Figure 4) who have expertise in an infectious disease. Profile creators can create Prevention Profiles independently of each other and are identified by Decentralized Identifiers (DIDs). These are identifiers that can be created decentrally and bound to public keys in a self-sovereign manner with the help of a Distributed Ledger Technology (DLT). ^{44 , 45} By using a DLT, the InfectPreventionApp can lookup the public key used by a profile creator to verify the signature of a Prevention Profile without the need for a Public Key Infrastruktur (PKI). Since the focus of this paper lies neither on DIDs nor on DLTs, these technologies will not be discussed further. It is assumed that a DLT is available that can be used jointly by profile creators and the InfectPreventionApp.

To enable a decentralized creation of Prevention Profiles, profile creators must know which interfaces they need to consider and which sensors can generate which data. They and the person being supported also need a common terminology when it comes down to possible pre-existing diseases, protection measures and pathogens. To create a common terminology, a Disease Catalog, a Protection Catalog and a Pathogen Catalog (see Figure 4) are used, in which the possible pre-existing diseases, protection measures and pathogens are defined.

A person’s situation can change over time. To enable a timely detection and defusing of threatening situations, the InfectPreventionApp leverages an Intervention Cycle. In this cycle, the sensor data is processed using the existing Prevention Profiles in order to assess the situation of the person being supported depending on a pathogen and to suggest protection measures to them. The assessment is based on the context (see Definition 4.1) of the person being supported, which requires an appropriate Context Representation. The result of the assessment and also of the cycle are Intervention Information which are generated based on the Prevention Profiles. The Intervention Information describe the threat posed by a situation and contain the protection measures that should be suggested to the person being supported. Thus, the requirements R1, R3 and R18 are addressed. In addition to that, Intervention Information can optionally include further data that describe a threat posed by the person being supported. If such data is available, it is made available by the InfectPreventionApp to other entities involved in the infection prevention via BLE in order to assist them in assessing the threat posed by the person being supported. Since the entire architecture does not rely on any central SP, requirement R2 is met.

7.2 Communication protocol

In order for the BLE information exchange described in Section 7.1 to take place in an organized way, a communication protocol is required, which is referred to below as Infect Prevention Information Exchange Protocol (IPEP) and is explained in more detail using Figure 5. The figure shows two entities (Alice and Bob) involved in the infection prevention. For Alice to be able to detect Bob’s presence in her environment, Bob must broadcast an ADVERTISEMENT message to his environment. If Alice can receive the message, she must be able to recognize that Bob is taking part in the infection prevention. Therefore, Bob must include a specific Universally Unique Identifier (UUID) in his ADVERTISEMENT message as an identifier for a BLE service that he offers (parameter infprevsrv_uuid). As it will become clearer later, this service is of particular importance, so that it is referred to below as Infect Prevention Service (IPS).

Figure 5:

Infect Prevention Information Exchange Protocol.

Recognizing the mere presence of an entity is not sufficient. According to the requirements R7 and R12, Alice must be able to distinguish, for example, whether Bob is a person or an object. To enable her to make this distinction, Bob must transmit a code for the type of his entity in the ADVERTISEMENT message (parameter type_code).

As long as Alice is within the range of Bob, she can receive several ADVERTISEMENT messages from him. According to R7 and R12 the number of present entities and according to R9 (in the case an entity is a person) the duration of an encounter should be taken into account for the recognition and defusing a threatening situation. Therefore, Alice must be able to recognize Bob. For him to be recognizable, Bob must include a random identificator (ID) in his ADVERTISEMENT message (parameter id), so that Alice can assign various ADVERTISEMENT messages to him. However, since a constant ID would mean that a person would always be recognizable, which would have an impact on the person’s privacy, the present concept allows a person to periodically change their ID.

While Bob is within the range of Alice, Alice must be able to estimate the existing distance to him, since according to the requirements R8, R13 and R14 it should be possible to take the distance into account. In order for Alice to be able to estimate the distance to Bob based on BLE, she needs, in addition to the measured signal strength with which she received his ADVERTISEMENT message, a reference value that indicates the expected signal strength of Bob’s BLE transmitter at a known distance. The expected signal strength depends on the BLE chip used and must be provided by the chip manufacturer. It is assumed that the expected signal strength at a distance of 1 m is known so that Bob can include it in his ADVERTISEMENT message (parameter mPower).

In order for Alice to be able to establish a connection to Bob and request further, optional information from him after receiving an ADVERTISEMENT message, she needs his Media-Access-Control (MAC) address. Therefore, Bob must also include his currently used MAC address in the ADVERTISEMENT message (parameter mac_addr). The connection establishment is part of the BLE protocol stack ⁴⁶ and is therefore not considered any further in this paper. Once the connection has been established, Alice must tell Bob which information she needs from him.

Since BLE requires that all data offered by an entity has to be organized hierarchically by services, characteristics and descriptors, ⁴⁶ the IPEP specifies that Bob must offer all information about himself, which could be relevant for the infection prevention, under the IPS. For each Prevention Profile used, Bob must provide a characteristic whose value describes the risk of infection or contamination originating from him related to a pathogen. Since the characteristic value is calculated based on Bob’s context and Bob’s past is therefore also included in the calculation of the value, requirements R10 and R15 are met.

Bob must further assign a set of descriptors to each characteristic to describe the following aspects of a threat he poses: the pathogen’s ID according to the Pathogen Catalog, the Prevention Profile used to calculate the threat and its signature, the time of the calculation and whether the posed threat is increasing or decreasing (threat flank).

The actual request of the information takes place iteratively. First, Alice has to determine all UUIDs of the characteristics that Bob offers under the IPS. She therefore sends him a CHAR_DISCOVERY message with the UUID of the IPS (parameter infprevsrv_uuid). Bob replies to the message with a CHAR_LIST message in which he includes the previously transmitted UUID of the IPS (parameter infprevsrv_uuid) and a list with the UUIDs of the characteristics he offers (parameter char_uuids).

For each of the UUIDs contained in the list, Alice must next request the characteristic value. She therefore sends Bob a CHAR_READ message. In order for Bob to be able to assign the requested characteristic to a service, Alice must include both the UUID of the IPS and the UUID of the requested characteristic in her message. Bob replies to the message with a CHAR_VALUE message that contains the requested value (parameter char_value) as well as the UUIDs previously transmitted to him. This enables Alice to assign his message to one of her original CHAR_READ messages.

Next, Alice must request the descriptors assigned to the received characteristic. To do this, Alice must first determine their UUIDs. She therefore sends Bob a DESCR_DISCOVERY message. In order for Bob to be able to identify for which characteristic the UUIDs of the descriptors are needed, Alice must include both the UUID of the IPS (parameter infprevsrv_uuid) and the UUID of the corresponding characteristic (parameter char_uuid) in her message. Bob replies to the message with a DESCR_LIST message in which he includes the requested list with the UUIDs of the descriptors (parameter descr_uuids) as well as the UUIDs originally transmitted to him, so that Alice, in turn, can assign his message to one of her originally sent DESCR_DISCOVERY messages. Alice now goes through the received list and sends a DESCR_READ message to Bob for each of the UUIDs contained in it, which Bob answers in the same way as a CHAR_READ message.

7.3 Sensors

As part of the infection prevention, each sensor is given a unique name using an Uniform Resource Name (URN). In addition, in this concept, the data generated by the sensors, together with their type and the time of their generation, are referred to as sensor events. They also have an URN that describes their type. The data included in a sensor event is encoded as strings. This is done because sensor events are processed in the Intervention Cycle using existing Prevention Profiles, which can be created decentrally (see Section 7.1). To enable profile creators to develop their Prevention Profiles independently of individual sensors, a neutral encoding of the data they generate is required. In this concept, strings are used for this purpose.

The sensors required for the infection prevention can be derived from the requirements identified in Section 5. In R7 to R10 and R12 to R15, it is required that the recognition and defusing of threatening situations should be possible depending on the number, distance, duration and past of the entities present in the environment of the person being supported. To detect the presence of the entities and to be able to obtain the necessary information about them, a proximity sensor is used, which executes the IPEP described in Section 7.2. The requirement R16 demands that the location at which a person being supported is present should be considered. So a location sensor is used to determine the location. It uses the GPS module in the local device of the person being supported to collect location coordinates and their accuracy. It is assumed that such a module is available in the person’s device. In R4, R5 and R11, it is required that the protection measures applied by the person being supported, their health condition and infection tests carried out by them should be taken into account for the recognition and defusing of a threatening situation. The information needed for this is collected by a protection, disease and an infection test sensor, which all react to interactions of the person being supported with the InfectPreventionApp and generate corresponding sensor events when the person reveals the respective personal data.

7.4 Context representation

To assess the situation of the person being supported based on their context, the data collected by the sensors must be transferred to a context model. However, it must be taken into account that the person being supported may use different Prevention Profiles, meaning that different requirements may arise for the scope of a context model required by a Prevention Profile.

7.4.2 Core model

Since the ontology-based approach has proven itself for modeling context (see Section 4.2), an ontology-based core model is designed for the infection prevention, which is referred to below as Infect Prevention Core Model (IPCM) and is presented in Figure 6. There, all concepts included in the model are depicted as nodes (ellipses in Figure 6) and the relations between them are depicted as edges (arrows in Figure 6). It is defined that all concepts and relations may be extended. In the following, extensions of the IPCM are referred to as IPCM extensions. IRIs (see Section 4.2) are used to identify all model elements, and it is defined that all elements of the IPCM belong to a namespace abbreviated by the prefix core.

Figure 6:

Infect Prevention Core Model.

A person is represented in the IPCM by the concept core:Person. Each core:Person can either be the person being supported or any other person, which is expressed by the concepts core:Me and core:Other, both of which extend the concept core:Person. A core:Person can be involved in various core:Interaction with themselves, another person or a core:Something. Alice can, for example, touch herself, meet Bob, enter a supermarket, put on a face mask or do an infection test. Every core:Person as well as each core:Something can have a threat, which is described by the concept core:Threat. A threat represents a risk of infection or contamination and can be further differentiated into an incoming and an outgoing threat. Thus, the concept core:Threat is extended by the two concepts core:IncomingThreat and core:OutgoingThreat. While an incoming threat describes a threat that exists at a given time for a core:Person or a core:Something, an outgoing threat describes a threat that a core:Something or a core:Person can pose to another core:Something or another core:Person. Since a threat of an entity can change over time and it is also important to be able to determine what threats existed at a particular point in time, a core:Interaction can have a reference to the threats that existed at the time of its occurrence. Each core:Interaction can also be further described by the concept core:InteractionDetail and each existing threat can have an impact on a core:Person or a core:Something, which is represented by the concept core:Impact. A person can have pre-existing diseases. Diseases are expressed by the concept core:Disease. As a person’s pre-existing diseases can have an influence on the possible severity of the course of an illness, every core:Disease can have an implication for an core:IncomingThreat (see relation core:hasImplicationFor). To protect themselves from an infection or the onset of an illness, a person can apply protection measures (see Section 3.2). These are expressed by the concept core:Protection. The relation core:isCapableOf is used to express which protection measures are possible for a core:Person. Similar to a pre-existing disease, a protection measure can also have an implication for an core:IncomingThreat. Since protection measures that have been applied can also protect others, a core:Protection can also have an implication for an core:OutgoingThreat. If Alice is infectious, for example, and is wearing a medical face mask correctly, this can make it more difficult for her to pass on a pathogen to other people around her.

7.5 Prevention profiles

Based on the considerations in Section 7.4, four central components of a Prevention Profile (see Figure 7) can be identified that must be provided by profile creators. As discussed in Section 7.1, Intervention Information describe a threat posed by a situation and contain protection measures to be suggested to the person being supported. This information always depend on a specific pathogen; therefore, to generate it, a Prevention Profile must include the Intervention Policy to be executed by the InfectPreventionApp. Since Intervention Policies are applied to a Contextualized State and since this state is generated by Contextualization Strategies, a Prevention Profile must also include these. Similarly, Contextualization Strategies require a State as an input, which is built up using Sensing Rules. Therefore, a Prevention Profile must also include the Sensing Rules to be executed by the InfectPreventionApp. Furthermore, since the previously presented components of a Prevention Profile may depend on an IPCM extension, a Prevention Profile must also include this.

Figure 7:

Components of a Prevention Profile.

7.6 Intervention cycle

Now that all the key components of the approach have been presented in the previous Sections 7.1–7.5, they can be integrated into the Intervention Cycle shown in Figure 8. The cycle consists of four elements: the person being supported, a Sensing Component, an Intervention Component and a Situation Information Component.

Figure 8:

Intervention Cycle.

The person being supported is the addressee of the Intervention Cycle. As a physical being, they have a location in the real world and are therefore surrounded by an environment. Depending on their actions, even if this means just passively staying at one place, the person may be affected by events in a current situation that could impact the threat the situation poses to them. The information about the situation is captured by the Sensing Component and transferred to a State with the help of the Sensing Rules defined in the existing Prevention Profiles. However, it must be taken into account that different Prevention Profiles could provide competing Sensing Rules. This must be addressed; otherwise, different profiles could interfere with each other in an unpredictable way. A similar argument can be made for the Contextualization Strategies. This problem can be avoided if all Prevention Profiles are considered as isolated components of the InfectPreventionApp. It follows that each Prevention Profile must have its own exclusive State and its own exclusive Contextualized State, so that there can’t be any interference between individual profiles. Therefore, the Sensing Rules contained in all Prevention Profiles are not used to establish a single global State; instead, a separate State and Contextualized State are generated for each profile.

The Intervention Component is responsible for generating the Intervention Information mentioned in Section 7.1. To do this, the component must first contextualize a State of a Prevention Profile using the Contextualization Strategies defined in it in order to generate a context (see Definition 4.1) of the person being supported that is relevant for the Prevention Profile. The Intervention Component is therefore notified by the Sensing Component as soon as all Sensing Rules of a Prevention Profile have been applied to a sensor event. As soon as all the Contextualization Strategies of a Prevention Profile have been executed and the Contextualized State is available, the Intervention Policy defined in the profile is finally executed to generate Intervention Information. All components of a Prevention Profile are executed in a sandbox. It is assumed that a sandbox is in place that blocks all network traffic and access to resources of other Prevention Profiles and the InfectPreventionApp unless the access is made by a service provided by the app that is known to the sandbox. In regard to the requirement R17, this allows profile creators to access third-party services in a controlled manner to determine the threat level of a given location based on its past. The generated Intervention Information must be returned by a profile creator as a string in JavaScript Object Notation (JSON), the structure of which is explained below using the example data shown in Listing 1. In the elements threatMe and threatOther, a profile creator must specify the threat posed to and posed by the person being supported. A threat must be described by its value (elements value), its flank (elements flank) and the time of its computation (element computationTime). To enable a uniform interpretation of threats, it is defined, based on membership functions from the field of fuzzy logic,^[1] that the value of a threat must fall within the closed interval [0, 1]. For the flank of a threat, it is further defined that it is rising if its value is positive. It is falling if its value is negative and otherwise it is unchanged if its value is 0. The element threatOtherSignature contains the signature of the threat posed by the person being supported. In the element protectionSuggestions, a profile creator must finally suggest protection measures that the person being supported can apply to protect themselves. Each suggestion must consist of an ID of the protection measure according to the Protection Catalog (element measureID), a priority of the measure (element priority) and an indication of the maximum duration of its protective effect (element lifespan).

Listing 1:

Structure and example data for Intervention Information.

The protection measures listed in the Intervention Information must not be passed on to the person being supported without being filtered. On the one hand, contradictory suggestions that may have arisen due to the execution of different Prevention Profiles must be identified and resolved. On the other hand, it must be ensured that the person being supported is not overwhelmed with too many suggestions. The Situation Information Component is responsible for selecting the protection measures that are actually suggested to the person being supported and also for informing them about a threat posed by a situation. The component is therefore notified by the Intervention Component as soon as new Intervention Information become available. The protection measures suggested by a Prevention Profile are then extracted from this information and filtered. Since the focus of this paper is not on the resolution of contradictory protection measures, it will not be discussed further at this point. Subsequently, the person being supported is informed about a threat posed by a situation and is shown by the (filtered) protection measures how they can defuse it. Thus, requirement R3 is addressed. If protection measures are applied or the situation of the person being supported changes in any other way, the Intervention Cycle restarts.