IRIS is conceptually incompatible with a.nwesen.de

[prechelt]

We talked about integrating my browser-based contact tracing application for universities, a.nwesen.de, with IRIS connect.
http://a.nwesen.de/
https://github.com/prechelt/anwesende

I have looked at it and now think that an integration does not make sense because the two applications tick too differently. Here is how:

• IRIS works in terms of locations and time intervals.
• This works well for small locations (such as small pubs with 20 people), not-so-well for mid-sized locations (such as large restaurants with 100 people), and not well for large locations (such as concerts with 1000 people).
• a.nwesen.de administrates a single very large organization (a university with several 1000 people) that has many individual rooms. An a.nwesen.de room is equivalent to an IRIS location.
• But a.nwesen.de also works at a finer grain: Visitors check in to a particular seat in a room and each seat has a known distance from any other seat in that room. Contact person data retrieved from a.nwesen.de spells out the distance of each person from the infected person, which is a great help for the Gesundheitsamt's work.
• For retrieving data to send to a Gesundheitsamt, a.nwesen.de works by identifying the infected person by name, phone number, or email address. This non-anonymous approach is OK for a.nwesen.de, because the distance data reveals the infected person anyway.
• To make a.nwesen.de work with IRIS, the infected person would need to transfer their location (by a seat) instead of only their personal data.
• This is difficult:
  • There is no app that stores the rooms visited, only the browser history. But many mobile browsers' history function does not list the dates and times of the URL visit and so is very difficult to use for reconstructing the visits.
  • Students would usually not know their seat numbers from the top of their heads. They would often not even know the room numbers of where they were. Matching student-provided imprecise seminar-room location data to an IRIS location list would be very cumbersome for a Gesundheitsamt official.

In short: The way how IRIS constructs a group of contact persons and the way how a.nwesen.de does it are sufficiently different that applying IRIS to a.nwesen.de would make life harder for the Gesundheitsamt rather than easier.

Is my above understanding of IRIS correct?
If so, no integration should be attempted.

[lucky-lusa]

We discussed a similar approach some time ago.

In itself, IRIS could map this case. For this purpose, it would be necessary that the name or the identification characteristics of the person are transmitted to a.nwesen.de when the request is generated by the health department. The name should be known to the health department anyway and you will get the name with your current implementation without IRIS from the health department as well, right?

If a.nwesen.de then receives the request, the matching could be performed and the corresponding data would be transmitted to IRIS in the regular way.

From my point of view, there would be no reason why we shouldn't discuss and explore in detail whether there is a quick way to provide you with the information you need for your matching.

[prechelt]

you will get the name with your current implementation without IRIS from the health department as well, right?

Actually no. The infected person will be affiliated with the university (as a member or student) and we require them to notify us at the same time as they inform the Gesundheitsamt. So we can retrieve the data proactively and send it to the Gesundheitsamt before they even ask. And if the information they provided is wrong or insufficient, we simply ask back.

As an important result, we can inform the contact persons very quickly.

As far as I know, the Gesundheitsamt told us that likely we will drive the whole contract tracing regime ourselves, because they will not have the capacity to do so.

[bkastl]

It's a Berlin thing where health departments outsource the notication process to the persons or organizations themselves, but it can occur in other occasions where universities have a slightly different legal basis towards keeping contact data. In some occasions they have most of the data anyway and know about infections anyway.

The problem in this scenario is that we send a health information to fulfill the request (infected person) which should be checked with data protection and security. There is only one reason you are be able to request data from a legal basis. Leaking this data would be the worst case.

So we could adapt IRIS for this type of request but I think it should require a special check if the requested application is allowed to retrieve this information. Only if this check passes we should send out a request like this.

Have to think about other implications on other parts of IRIS but I think that could be a way we could handle this type of request.

[topialla]

instead of the name, we discussed using the phone number, which should work quite well, as there are less typo-possibilities and a mostly unique matching (except if people mistype their phone number at either place). What do you think of that @lucky-lusa @bkastl ?

[adewes]

Closing this as I think it's outdated now, thanks for the discussion everyone!