The reliability of the information that the user notified by the app was indeed in a risky encounter with an infected person depends on two main factors:

  • environment parameters that are "invisible" for the app (e.g. whether users are wearing masks, facing each other or not, they are separated by a plexiglass partition etc.)
  • technical parameters of the reliability of measuring distance via the Bluetooth signal in various mobile devices (this is affected by the Apple/Google protocol, battery level, position of the phone on the user's body, their movement etc.)

The reliability cannot be 100%. Due to the anonymous schema of the Apple/Google Exposure Notification it is impossible to verify identified risky encounters in other ways (such as who met whom, where, and when etc.).

In a small part, a false evaluation of a non-risky encounter as a risky one (false positives) or a false evaluation of a risky encounter as a non-risky one (false negatives) might take place. From an individual's perspective, this seems to be a poor rate of reliability (to force them to stay at home in vain). However, from the society's public health perspective, it is critical to inform people about most risky encounters as soon as possible to stop the spread of the infection, regardless of a small imprecision.

The technical parameters of measuring distance depend primarily on the implementation of the Exposure Notification API in Google's and Apple's systems in mobile phones. Number of measurements in time is an important factor which affects the precision of measurement. At the same time, this parameter increases battery use so it is being constantly balanced in Google's and Apple's implementation.

The reliability can be influenced by setting parameters of risky encounter evaluation on the app's side. The eRouška team performed internal testing of parameter settings and evaluation reliability, and compared it with settings in other apps from Germany, Austria, the Netherlands and Switzerland. Based on these tests and comparisons, we chose the starting set of parameters to evaluate a risky encounter which is published here.

The eRouška team will continue testing new versions of implementation of the Apple/Google API in operating systems, gather new knowledge from the Czech Republic and other countries, and optimise parameters of risky encounter evaluation. We will also publish related information on this page.

Note: Information on this page comes from the documentation and experience with using the Apple/Google Exposure Notification API. Apple and Google might change the described behaviour as new implementation versions arrive.

Risky encounter evaluation

The app, which uses the protocol of Apple/Google Exposure Notification (as eRouška 2.0 – below as "Application"), transmits encrypted keys using the Bluetooth Low Energy (LE) technology, periodically scans its surroundings, and saves detected keys from Applications on other devices. Along the keys, the Application saves their signal strength, time period of the encounter, and date when it took place.

If the Application user is infected with COVID-19, they will receive an authentication code from the public health office and will be able to send their Application's random keys to the server, from which all other devices with the Application will download them. Then, Applications on those devices will establish if the keys of the infected person are among keys that they had scanned before. If they are, the Application will evaluate whether the encounter was risky or not.

eRouška considers an encounter with an infected person risky if it is closer than 2 metres and longer than 7 minutes.

The Application monitors the signal strength and length of the encounter to evaluate it. Signal strength is used to estimate the distance of the device.

Apple and Google work on decreasing the impact of these limitations and on maximising the evaluation's reliability. In June, the Dutch application reported over 20% of false positives and over 20% of false negatives. Similar values were reported by proof-of-concept tests of the eRouška team and also by German app Corona-Warn-App in July. Since then, new versions of the API implementation which specify measurement parameters more precisely were published. For example, a comparison of signal strength was implemented in Apple/Google API 1.6. For each device, there is a specified correction sent out in the encrypted identifier which is used to adjust the detecting device's signal strength. The number of measurements in time was increased in iOS 13.6.

We chose the setting of German Corona-Warn-App as entry parameters, but we use a newer version of API. The parameters and how they are used to calculate the level of risk are as follows.

Mode of evaluation

Apple/Google Exposure Notification ("EN") system offers the following ways to calculate the level of risk:

Contagiousness evaluation

A standard epidemiological investigation between a public health officer and the infected user of the Application is a necessary precondition to use the Application for Smart quarantine. In this investigation, the first day of symptoms is established. If the infected user agrees to send encrypted keys from their device, the public health officer sends the date of symptoms to the server. On the server, this date of symptoms is joined with the keys from the infected user's device.

Based on the date when the infected person felt the symptoms first, the Application defines the day when the individual was contagious. It is currently set to two days before they experienced the symptoms first (i.e., one day before the day that preceded the day when they felt the symptoms for the first time).

Only encounters during the days when the individual was considered contagious can be evaluated as risky encounters.

Risk bucket evaluation

The goal of the current setting is to reach the desired state when encounters closer than 2 metres and longer than 7 minutes are evaluated as risky, and situations when these conditions were not fulfilled are evaluated as non-risky.

The Application developers established 3 levels of signal attenuation which create 4 risk buckets. Attenuation is a unit measurable via signal strength. The higher the attenuation level, the lower the signal strength.

  • Immediate risk bucket for attenuation levels lower than the lowest of these values
  • High risk bucket for attenuation levels between the lowest and medium value
  • Medium risk bucket for attenuation levels between medium and the highest value
  • Low risk bucket for attenuation levels higher than the highest value

Buckets of immediate, high, medium and low risk. Limits are 55, 70, and 80 dB.

The developers then establish the constant for each bucket (0%–250%). The encounter length in minutes is then adjusted by the constant of its bucket.

We chose the settings recommended by Apple and Google which was published in December 2020 and focuses on sensitivity. It means that the length of an encounter within the immediate risk bucket is adjusted by a constant of 200% (i.e., multiplied by 2), the length within the high risk bucket has a constant of 100% (no impact), the length in the medium risk bucket has a constant of 25%, and the length in the low risk bucket has 0% constant (i.e., is not calculated at all).

Finally, the app developers establish the level of minimal risk score (in minutes). If the total time of the encounter adjusted with the constants is greater than or equal to minimal risk score, the encounter is evaluated as risky and the exposure notification is displayed. If the total time is lower than the minimal risk score, the encounter is considered to be non-risky.