[Update] Założenia projektu ProteGO Safe

[MateuszRomanow]

Cześć,
W ostatnim czasie wzrosła dynamika issues i komentarzy w nich. Jest ich tyle, że trudno na wszystkie odpisać. Dlatego zakładam ten wątek, żeby wszystkie najbardziej konkretne kwestie oraz chronologię projektu opisać w jednym miejscu. Szczera intencja jest też taka, żeby rozwiać dużo mitów, które narosły wokół projektu.

Po pierwsze - założenia
Zaczęliśmy projekt SafeSafe w jednym celu - dostarczenia narzędzia, któe przyspieszy odmrażanie gospodarki i wychodzenie z lockdownu. Ten kontekst jest bardzo ważny. Każdy tydzień, czy miesiąc odmrażania później to większa recesja, z którą się zmierzymy. Na początku marca (zaraz będą dwa miesiące… ) stworzyliśmy kilka prototypów rozwiązań informatycznych, które mogą pomóc. Było skanowanie kodów QR, był GPS tracking, bluetooth tracing i hybrydy. Po analizie szybko okazało się, że to fajne “automagiczne” rozwiązania, ale długie w procesie R&D, skomplikowane, niepewne. Instytut Roberta Kocha, WHO i nasz konsultant merytoryczny dr hab Grzegorz Garbacz mówili jedno - profilaktyka, profilaktyka i jeszcze raz profilaktyka. 90-95% nowych zarażeń można uniknąć poprzez dobrą profilaktykę. To mało “przełomowe” rozwiązanie, nie dzieje się w chmurze, nie jest rewolucyjne, ale jest skuteczne. Dlatego aplikację SafeSafe oparliśmy o tą funkcjonalność. Skorzystaliśmy z API firmy Infermedica, bardzo doświadczonej w obszarze telemedycyny. Z tego API korzysta równolegle kilkadziesiąt (w tym pacjent.gov.pl) rozwiązań COVID-19 na całym świecie. Drzewko decyzyjne jest rozwijane przez ~20 lekarzy, którzy są w kontakcie z MZ, GIS i monitorują WHO.

Od lekarzy, którzy są na pierwszej linii frontu, dostaliśmy feedback, że bardzo utrudnia im pracę, kiedy do szpitala trafia chory bez opisu dolegliwości i swojej historii. W ten sposób lekarze tracą dużo czasu na kompletowanie takiego wywiadu medycznego. Odpowiedzieliśmy na to “Metryczką Zdrowia” która jest w aplikacji i można ją w łatwy sposób wyświetlić w szpitalu.

Kolejny problem, zgłaszany przez lekarzy (mocno opisywany przez niemieckich epidemiologów z którymi dr Garbacz ma kontakt) to brak historii przebiegu choroby po stronie pacjenta. Szczególnie dotkliwy wśród seniorów - przyjeżdżając do szpitala często nie mają zapisanych notatek o przebiegu choroby (temperatura, objawy, odwiedzone miejsca) a lekarz musi poświęcić znacznie więcej czasu na taki wywiad. Odpowiedzią na tą potrzebę jest “Dziennik Zdrowia” który znajduje się w aplikacji.

Kiedy z naszej oddolnej darmowej aplikacji, którą stworzyliśmy społecznie skorzystało 35 tys. Użytkowników, Ministerstwo Cyfryzacji a dokładniej GovTech zaczął z nami rozmawiać o tym, jak można wykorzystać SafeSafe w odmrażaniu gospodarki. Najbardziej spektakularnym wdrożeniem ( i na tamtą chwilę najbardziej komunikowanym jako skuteczne) było wdrożenie Singapurskiego TraceTogether wykorzystującego Bluetooth tracing. MC poprosiło nas o zaproponowanie rozwiązania, które mogłoby podobnie pomóc.

Ważne: od samego początku, rozważaliśmy TYLKO jako docelowe rozwiązanie zdecentralizowany model na bazie własnego rozwiązania a później OpenTrace i G&A. Pierwszy prototyp mieliśmy gotowy 04.04 - polegał na wysyłaniu historii rotowanych ID osoby zakażonej do wszystkich innych użytkowników systemu, z których każdy miał lokalnie sprawdzić czy się z nią widział i dostać stosowny warning. Dzisiaj skądś to znamy ;). Zarzuciliśmy ten projekt na rzecz zanonimizowanego OpenTrace, który był znacznie bardziej dojrzały.

Po drugie - chronologia zdarzeń

15.03 - pierwszy publiczny apel o wsparcie specjalistów z różnych dziedzin.

20.03 - tworzymy grupę testerską, do której zapisało się 1200 osób (!)

23.03 - równolegle do pracy nad SafeSafe ruszyliśmy z akcją dostarczania pralek ( i innych sprzętów AGD) do szpitali - problemy, które do nas docierały przy okazji budowania rozgłosu o SafeSafe to problem z dezynfekcją i praniem roboczych ubrań przez ratowników medycznych. Dostarczyliśmy w sumie sprzęty do około 30 szpitali i placówek medycznych np. POGOTOWIE Ratunkowe we Wrocławiu, Szpital Trzebnica, Szpital Świnoujście, DIVEMED Jelenia Góra. Sprzęty podarowały firmy takie jak AB S.A, BSH, Elektrolux . Kluczową rolę odegrała tu m.in. Aga Sawczyńska.

27.03 - wystartowało SafeSafe pod adresem koronazglowy.com. Kilka dni później pisałem o tym tutaj powstało też o nas sporo artykułów, w tym np. Ten w POLITYCE

29.03 - dostałem informację od GovTech, że dostali nasze zgłoszenie i analizują temat;

30.03 - kontaktujemy się z Niebezpiecznikiem z prośbą o darmowy, społeczny audyt aplikacji SafeSafe. Dostaliśmy odmowę.

03.04 - dołączyła do nas ekipa Sigma Connectivity, która wykonałą PoC modułu Bluetooth, który zaimplemetowaliśmy testowo do aplikacji. Równolegle Kuba Lipiński tworzył już projekt ProteGO także od zera. Mniej więcej od tego momentu kontaktowaliśmy się już z Singapurem w sprawie TraceTogether żeby zebrać banchmark.

09.04 - Blue Trace udostępnia kody do OpenTrace

10.04 - Dzień później Google i Apple ogłaszają swoją inicjatywę. Tego samego dnia rozmawialiśmy z MC sugerując, że w obecnej sytuacji najlepszym rozwiązaniem będzie wstrzymanie prac nad autorskimi rozwiązaniami do contact-tracingu i skupienie się na integracji OpenTrace a w przyszłości integrację z G&A. MC zapytało nas, czy możemy (jako konsorcjum wcześniej zaangażowanych w to firm) przyjąć taki projekt i poprowadzić to wdrożenie. Zgodziliśmy się. MC podjęło decyzję, żebyśmy wspólnie stworzyli taki projekt.

11.04 - Kuba Lipiński informuje, że Ważne zmiany w projekcie #94

--- tu kończy się etap ProteGO i zaczyna się ProteGO Safe ---

15.04 - nawiązujemy kontakt z przedstawicielem Google w sprawie API.

17.04 - podsumowuję intencje projektu (informując o tym, że OpenTrace będzie integrowany - kody do aplikacji były znane od 09.04 każdy mógł je przeanalizować)

19.04 - podsumowanie podstawowych założeń projektu #104

25.04 - opublikowaliśmy kody do aplikacji iOS, Android i PWA

28.04 - Ministerstwo Rozwoju opublikowało informację o udziale ProteGO Safe w odmrażaniu Galerii Handlowych, które nie było zgodne z założeniami projektu. 1h po konferencji PRM skontaktowaliśmy się z MC w celu jasnego stanowiska, czy założenia projektu nie są podważone. PO 3h zostało opublikowane sprostowanie a błędny zapis został usunięty z wytycznych.

29.04 - kontakt z Niebezpiecznik i LogicalTrust. Efekt: brak odpowiedzi od Niebezpiecznik, propozycja terminu od LogicalTrust

30.04 - kontak z Securitum. Efekt: współpraca w zakresie data security i data privacy nad ProteGO Safe.

02.05 - koniec analizy dokumentacji do zamkniętej bety Google.

04.05 - oficjalna decyzja MC o nakierowaniu dalszych prac wokół integracji API G+A.

Po trzecie - założenia [w aktualizacji]

Zakładamy, że:

1. Aplikacja powstaje po to, aby umożliwiać przyspieszenie znoszenie lockdown (predykcja kontaktu z osobą chrobą na COVID-19) oraz zmniejszać napiecie społeczne (poprzez wiedzę - o moim stanie zdrowia, o tym jakie są zalecenia rządowe).
2. Priorytetowo traktujemy kwestie privacy i security.
3. Od początku (14.03.2020) projektu SafeSafe, który od 11.04.2020 przekształcił się w ProteGO Safe dopuszczaliśmy dwa scenariusze finalnego wdrożenia: model maksymalnei zdecentralizowany zbudowany jako hybryda rozwiązań OpenTrace lub wdrożenie API G+A kiedy będzie opublikowane. Po konsultacjach z Google w dniach 02.05 i 04.05 Od dnia 04.05 MC podjęło decyzję, żeby skupić się na realizacji drugiego scenariusza opertego o API G+A.
4. Dane przechowywane są na urządzeniu użytkownika; użytkownik może je w każdej chwili usunąć z aplikacji; dane usuwają się automatycznie po 21 dniach [od kolejnej wersji aplikacji czas magazynowania zostanie skrócony do 14 dni]
5. Użytkownik z chorobą potwierdzoną przez Health Authority będzie przesyłał do innych użytkowników tylko informacje o swoim DiagnosisKey/TempID (nie przesyła informacji o spotkanych urządzeniach).
6. Czyste dane BLE nie pozwalają na precyzyjną predykcję ryzyka zarażenia.
7. Potrzebny jest moduł analityczny, który analizuje dane i ocenia kontakt bezpośredni.
   W rozwiązaniu G+A jest to moduł "blackbox", który ocenia ryzyko w skali 1-8.
   [prace wstrzymane] W rozwiązaniu własnym, moduł analityczny zakłada analizę m.in. siły sygnału i wizualnie obrazuje "pewność" kontaktu oraz przewidywaną odległość. Te dane wymagają finalnego określenia parametrów styku przez GIS i MZ. 6. Obliczenie, czy miałem kontak z osobą zarażoną, oraz w jakiej grupie ryzyka się znajduję odbywać się będzie tylko na urządzeniu użytkownika końcowego.
8. API A+G będzie dostępne do 10.06.2020
9. IP użytkownika nie będzie przekazane organom rządowym.
   [w aktualizacji]

Po czwarte - technologia
W skład “systemu” ProteGO Safe wchodzą elementy:

A. Opublikowane produkcyjnie do 02.05:

1. Aplikacija iOS (repo) / licencja GPL-3.0
2. Aplikacja Android (repo) / licencja GPL-3.0
3. PWA / repo / licencja GPL-3.0
4. Backend OpenTrace (Cloud Functions) / opublikowany tutaj na licencji Apache 2.0
5. API Proxy do Infermedica (pliki konfiguracyjne Nginx) / dostępny tutaj / licencja AGPL

B. W fazie developingu:

1. Serwer centralny posiadający funkcje:

• Generowanie w czasie rzeczywistym puli kodów PIN, po przedstawieniu się którymi, aplikacja użytkownika końcowego dostanie pozwolenie na przesłanie historii swoich TempID/ Diagnosis Key / Licencja AGPL
• Po autoryzacji PIN przez użytkownika w porozumieniu z centrum kontroli urządzenie generuje tymczasowy token, który pozwala aplikacji na przesłanie danych.
• Przesłania dalej na urządzenia końcowe pozostałych użytkowników aplikacji TempID/ Diagnosis Key zarażonego urządzenia.
• NIE zapisuje permanentnie żadnych danych na serwerze (są usuwane po 14 dniach).
• Kod zostanie opublikowany po wytworzeniu w organizacji ProteGO-Safe na w/w licencji .

2. Moduł Analityczny [wstrzymany z powodu integracji z A+G]

• Napisany w Python’ie. W tym momencie w trakcie przepisywania na C -> w celu dokonywania obliczeń lokalnie na urządzeniu a nie na serwerze centralnym (jako alternatywa dla modułu analitycznego G+A). Funkcje:
• Walidacja czy moje urządzenie widziało się z TempID zarażonego przesłanym przez Serwer Centralny
• Obliczenie, do jakiej grupy należał nasz kontakt (NiskaGrupaRyzyka, ŚredniaGrupaRyzyka, WysokaGrupaRyzyka)
• Zaktualizowanie statusu predykcji na urządzeniu
• Przewidywana licencja GPL-3.0

3. Operator Backend (codename: OP-BACKEND)

• Napisany w: Java, Spring. Funkcje:
• Narzędzie pracy dla operatorów wyznaczonych przez Health Authority w Centrum Kontaktu w celu nawiązania kontaktu telefonicznego z zarażonym
• Umożliwia wyświetlenie operatorowi na ekranie losowego kodu PIN z puli wygenerowanej na Serwerze Centralnym, który wpisany przez chorego na jego urządzeniu (po przedyktowaniu podczas rozmowy telefonicznej) odblokuje czasową możliwość wgrania danych (historii TempID/Diagnosis Key chorego z ostatnich 14 dni), które zostaną rozpropagowane (przekazane) przez serwer centralny na urządzenia wszystkich innych użytkowników.
• NIE zapisuje kodów PIN. Jedynie wyświetla je operatorowi jako jednorazowe zdarzenie. Zdarzenie jest ograniczone czasowo. Po upłynięciu czasu kod staje się nieważny.
• Operacja analizy czy moje urządzenie miało kontakt z osobą zarażoną odbywa się lokalnie na urządzeniu. Operacja ta nie jest wykonywana centralnie na serwerze centralnym. Serwer centralny nie posiada informacji o parze kontaktów, ponieważ użytkownik wysyła tylko swoje dane (bez danych innych napotkanych urządzeń). To gwarantuje, że nie ma możliwości powiażania tych danych przez serwer centralny w jakikolwiek sposób.

Update:
Moduły 1 i 2 nie są dostarczone w rozwiązaniu G+A. Te moduły operator aplikacji musi wykonać samodzielnie i zintegrować z G+A.
Moduł 3 wymaga operacyjności potwierdzonej i sygnowanej przez Local Health Authorit. Tutaj także nie dostajemy gotowego rozwiązania, tą część procesu musimy stworzyć samodzielnie. Local Health Authorit w PL to MZ i/lub GIS.

4. API GOOGLE + APPLE

• Dokumentacja od G+A jest w trakcie analizy
• Implementacja G+A jest w trakcie przygotowywania od 03.05.2020 włącznie.

C. Data and privacy security

• Współpracujemy z Securitum na poziomie konsultacji oraz audytu.
• Niezależne testy przeprowadza firma Seqred
• Jesteśmy w kontakcie z Fundacją Panoptykon i odpowiadamy na pytania.
• Jesteśmy zgodni z wytycznymi i standardami Toolbox .
• Jesteśmy w stałym kontakcie i konsultacjach z eHealth Network.
• Dane użytkownika, może usunąć ze swojego urządzenia z poziomu aplikacji tylko sam użytkownik w dowolnie wybranej chwili.
• Dane związane z historią TempID użytkownika są automatycznie usuwane po 21 dniach od chwili ich zapisania.

D. Dalsze plany:

• Implementacja rozwiązania G+A w połączeniu z najlepszymi praktykami oraz doświadczeniem zdobytym do tej pory w projekcie ProteGO i SafeSafe - w taki sposób aby osiągnąć zamierzone cele.
• Dokumentacja zostanie opublikowana na otwartej licencji GPL/AGPL w repozytorium “specs” projektu ProteGO Safe w chwili uzyskania funkcjonalnego rozwiązania.
• Problemy do rozwiązania w implementacji Google & Apple:
• https://www.latimes.com/business/technology/story/2020-05-01/coronavirus-contact-tracing-apple-google
• https://medium.com/@jst.janik/koronawirus-m%C5%82ot-i-taniec-3bf0924fc608

Dla zmniejszenia czasu odpisywania, polepszenia przepływu informacji i zmniejszenia blokerów, moderacją zajmować się będą dodatkowo @Tarvald i @kamilgthecoders

W tym issue będziemy aktualizować informacje o podejmowanych kolejnych działaniach.