PACJENT "ZAKAŻONY": co dalej z jego Appką, " PAUZA" ?

Załóżmy że wszytko jest OK technicznie i użytkowo, ProteGO śmiga na API A+G, a aplikacji używa w Polsce prawie każdy.

Pojawiają się jednak zagadnienia do przemyślenia workfkow i pewnie warto takie możliwości przedyskutować np.:

1) Pacjent zdiagnozowany, logi tracingu opublikowane do centralnej bazy poprzez autoryzację aplikacji przez rządowy serwer: a) czy aplikacja automatycznie powinna zostać następnie "auto-zablokowana" po przesłaniu tych logów czy nie ?

b) jeżeli powinna być blokowania to na jak długo ? 14 dni? O tej chorobie nadal wielu rzeczy nie wiemy w kwestii nabycia odporności więc nie można założyć że przechorowanie załatwia sprawę.

c) a może do momentu uzyskania statusu "ozdrowieńca" - zatem powinien istnieć jakiś mechanizm "odblokowania aplikacji" jeżeli istniałby mechanizm jej auto-blokowania ? Rozumiem że status chorego zmieniany na zdrowego musiałby realizować ten sam serwer GIS/MZ, który przechowuje te centralne dane (ogłaszane łącznie codziennie).

2) Jeżeli aplikację zablokujemy i pacjent:

a) trafia do szpitala to "odpowiedzialność za jego izolację" spada na służbę zdrowia, bo wiadomo że jest chory - aplikacja wyłączona. Jeżeli nie byłaby wyłączona to wiadomo że telefony personelu będą "łapać" ciągle te logi i na pewno wiele osób zapomni apke w pracy wyłączyć (tutaj od razu pomysł na auto-pause po GPS w ustawieniach użytkownika dla danego obszaru/rejonu).

b) nie ma poważnych objawów to trafia do izolacji domowej to czy wtedy przy wyłączonym odgórnie ProteGo powinien mieć obligatoryjnie włączoną aplikację a'la "Kwarantanna Domowa" (jakaś "Izolacja Domowa"?)

c) w trybie b) nie zastosuje się do izolacji i "ruszy w miasto" (z telefonem) to czy jednak dla dobra społecznego ProteGo nie powinno być jednak bez dezaktywacji dla osób w izolacji "domowej" ?

d) jeżeli zostałoby popełnione przestępstwo c) to wtedy musiałby istnieć obligatoryjny mechanizm "ponownego opublikowania kluczy", ale jak ten proces katalizowac ? GIS ? Policja ?

e) jeżeli na izolacji domowej nawet złapie sąsiada w bloku przypadkiem przez drzwi to i tak nie będzie miał w jaki sposób skatalizować opublikowania logu i niby nie ma problemu...

f) ... ale d) spowoduje ponowne rozesłanie kluczy nawet dla sytuacji e) niestety

Czy możesz pogłębić "auto-zablokowana"? Przypomnę, że oprócz samooceny i TRIAGE aplikacja oferuje:

dziennik zdrowia (funkcjonalny także w trakcie/po chorobie choć zgadzam się, że marginalnie używany)
pytania i odpowiedzi (funkcjonalne także w trakcie/po chorobie)
funkcja informatywna (szpitale zakaźne, możliwość poszerzenia o aktualność)

Więc na "w trakcie" i "po chorobie" dostarczacie wiarygodnych informacji wydaje się najlepszym pomysłem

Pacjent zdiagnozowany, logi tracingu opublikowane do centralnej bazy poprzez autoryzację aplikacji przez rządowy serwer: a) czy aplikacja automatycznie powinna zostać następnie "auto-zablokowana" po przesłaniu tych logów czy nie ?

Chyba nastąpiło pewne niezrozumienie dzialania. To że aplikacja działa, nie znaczy że masz status "zarażasz". Aplikacjia na bieżąco jedynie zbiera dane. O tym czy ostatnie X-dni byłeś potencjalnie zarażający, czy nie, decyduje lekarz. Aplikacja powinna według mnie dalej zbierać dane. Przypomnę, że dane są zbierane tylko lokalnie. Wysyłane są na serwer jednorazowo, wtedy kiedy ktoś zostanie zdiagnozowany i lekarz określi ile dni wstecz dana osoba zarażała. Zakładam że osoba zdiagnozowana musi mieć (w tej chwili to jest obligatoryjne) zainstalowaną aplikację "Kwarantanna Domowa" która pilnuje, czy kwarantanna jest przestrzegana. Zakładając że tak jest, po 14 dniach od diagnozy osoba (na pewno) będzie zbadana jeszcze raz i zakładam że lekarz będzie w stanie określić ile dni od momentu postawienia diagnozy ta osoba zarażała. I wtedy powinno to zostać wysłane na serwer (tylko za te dni) - w razie czego żeby wyłapać kontakty które nastąpiły mimo kwarantanny domowej/szpitalnej.

Ale gdyby tak nie było aplikacja ProteGO-Safe mogła by być wykorzystana ponownie do wysłania x-dni wstecz natychmiast jeśli warunki kwarantanny zostały złamane i osoba chora na tym została "przyłapana" - tak żeby obsłużyć "złamanie kwarantanny". Dlatego aplikacja powinna działać cały czas i zbierać dane. O tym jak czesto i kiedy dane osoby chorej powinny być wysłane powinien decydowaać GIS/lekarze.

b) jeżeli powinna być blokowania to na jak długo ? 14 dni? O tej chorobie nadal wielu rzeczy nie wiemy w kwestii nabycia odporności więc nie można założyć że przechorowanie załatwia sprawę.

Nie ma takiej potrzeby. Dane można zbierać cały czas, to nic nie zmienia. O tym, czy zostaną wysłane decyduje diagnoza i lekarz. Więc nic nie trzeba zakładać odgórnie. Wszystko jest decyzją lekarzy.

c) a może do momentu uzyskania statusu "ozdrowieńca" - zatem powinien istnieć jakiś mechanizm "odblokowania aplikacji" jeżeli istniałby mechanizm jej auto-blokowania ? Rozumiem że status chorego zmieniany na zdrowego musiałby realizować ten sam serwer GIS/MZ, który przechowuje te centralne dane (ogłaszane łącznie codziennie).

Jak wyżej. Jest to niepotrzebne.

Jeżeli aplikację zablokujemy i pacjent:

a) trafia do szpitala to "odpowiedzialność za jego izolację" spada na służbę zdrowia, bo wiadomo że jest chory - aplikacja wyłączona. Jeżeli nie byłaby wyłączona to wiadomo że telefony personelu będą "łapać" ciągle te logi i na pewno wiele osób zapomni apke w pracy wyłączyć (tutaj od razu pomysł na auto-pause po GPS w ustawieniach użytkownika dla danego obszaru/rejonu).

Nie ma takiej potrzeby. Jak wyżej. Aplikacja jedynie zbiera dane a to czy dane (przeszłe) dni danej osoby są oznaczane jako "zarażające" decyduje lekarz podczas diagnozy.

b) nie ma poważnych objawów to trafia do izolacji domowej to czy wtedy przy wyłączonym odgórnie ProteGo powinien mieć obligatoryjnie włączoną aplikację a'la "Kwarantanna Domowa" (jakaś "Izolacja Domowa"?)

Jak wyżej. Kwarantanna Domowa jest obligatoryjna dla chorych (w trakcie gdy są na kwarantannie i potem powinna być odinstalowana). Przy wszystkich zastrzeżeniach co do jej prywatności uważam że to dobre rozwiązanie.

c) w trybie b) nie zastosuje się do izolacji i "ruszy w miasto" (z telefonem) to czy jednak dla dobra społecznego ProteGo nie powinno być jednak bez dezaktywacji dla osób w izolacji "domowej" ?

Jak wyżej. ProteGo powinno zbierać dane cały czas. Lekarz i GIS decydują kiedy i ile dni zostaną wysłane na serwer.

d) jeżeli zostałoby popełnione przestępstwo c) to wtedy musiałby istnieć obligatoryjny mechanizm "ponownego opublikowania kluczy", ale jak ten proces katalizowac ? GIS ? Policja ?

Jak wyżej. ProteGo powinno zbierać dane cały czas. Lekarz i GIS decydują kiedy i ile dni zostaną wysłane na serwer. Za każdym razem do wysłania będzie potrzebny nowy klucz.

e) jeżeli na izolacji domowej nawet złapie sąsiada w bloku przypadkiem przez drzwi to i tak nie będzie miał w jaki sposób skatalizować opublikowania logu i niby nie ma problemu...

Jak wyżej. ProteGo powinno zbierać dane cały czas. Lekarz i GIS decydują kiedy i ile dni zostaną wysłane na serwer. Zakładając na przykład że ktoś siedział na kwarantannie i wyzdrowiał i lekarz stwierdzi że ktoś zarażał o 10-6 dni wstecz, Wtedy Daily Diagnosis Key za te dni powinny być wysłane na serwer (przy okazji stawiania diagnozy "zdrowy") do tego będzie potrzebny nowy klucz od GIS i lekarz który stwierdzi kiedy dany pacjent zarażał, Jeśli w tym czasie osoba na kwarantannie spędziła pół godziny na piwie z sąsiadem i siedzieli blisko siebie sąsiad dostanie informacje że jest zagrożony. Zakładam że wtedy pójdzie na testy, zbada się i okaże się co robić dalej.

f) ... ale d) spowoduje ponowne rozesłanie kluczy nawet dla sytuacji e) niestety

Jak wyżej. ProteGo powinno zbierać dane cały czas. Lekarz i GIS decydują kiedy i ile dni zostaną wysłane na serwer.

Jasne, przepraszam za skrót myślowy jeśli niejasno opisałem. Rozważane "auto-zablokowanie" dotyczyloby tu wyłącznie kwestii związanych z proximity tracing czyli aplikacja przestałaby zarówno się rozgłaszać jak i nasłuchiwać.

Taka blokada włączałaby się po uploadzie swoich kluczy/logu na serwer przy oznakowaniu-potwierdzeniu zakażenia u danej osoby.

Wszystkie inne funkcjonalności oczywiście pozostawałyby niezmienione i jak najbardziej są potrzebne.

Rozważane "auto-zablokowanie" dotyczyloby tu wyłącznie kwestii związanych z proximity tracing czyli aplikacja przestałaby zarówno się rozgłaszać jak i nasłuchiwać.

Jak wyżej. Nie ma takiej potrzeby. Dane można zbierać cały czas, to nic nie zmienia. O tym, czy zostaną wysłane decyduje diagnoza i lekarz. Więc nic nie trzeba zakładać odgórnie. Wszystko jest decyzją lekarzy.

Zgadzam się - w tym przypadku jeśli upload jest "jednorazowym" działaniem katalizowanym każdorazowo/jednokrotnie to tak będzie.

Słuszna uwaga @potiuk że ewentualne wykorzystanie loga przy ocenie zdrowia osoby z "izolacji domowej" (przy wymogu uruchomienia aplikacji) pozwalałoby oszacować kwestie rygorystycznego jej przestrzegania

Jest jeszcze jedna - podkreślam czysto teoretyczna kwestia:

Aktualnie rozważamy chyba lokalnie/polskie działanie na serwerze ale przypuszczalnie mogą docelowo pojawić się "europejskie" a nawet "ogólnoświatowe" serwery zbierające wszystkie klucze bo w końcu ludzie zaczną podróżować i świat ustali jakiś poziom "nowej normalności".

Czy nie wydaje się Wam że w takiej sytuacji te potencjalne (niestety) miliony zakażonych osób ze zunifikowaną w jakiejś części aplikacją (pomimo tego że są "zakażone" i niczego to nie zmienia) będą w teoretycznych "codziennych sesjach nocnych" niepotrzebnie łączyć się z serwerem i porównywać swoje klucze do tych rozgloszonych ? Chodzi o niepotrzebne obciążanie serwera/serwerów.

A nawet przy lokalnym-polskim serwerze z kluczami czy rozważano jakoś teoretycznie jak podobne rozwiązanie będzie stabilne jeżeli powiedzmy 20mln użytkowników "co noc" będzie otwierać sesje celem porównywania swoich kluczy z bazą ? Czy to nie jest może jakiś potencjalnie słaby punkt rozwiązania A+G ?

Wtedy takie "auto-blokowanie" aplikacji przez osoby zdiagnozowane (jeśli, tak jak się obawiam będzie ich bardzo dużo...) potencjalnie odciążyłoby system oo stronie serwera, i ta "pauza" dotyczyłaby "porównawczych sesji nocnych".

Właśnie sobie uświadomiłem że opisany przeze mnie b.ułomny-amatorski pomysł w #102 jest z założenia pozbawiony jakiejkolwiek możliwości "przeciążania systemu" bo de facto jedyną styczną z systemem jest jednorazowy, jeden SMS :-)

Drugą (niedocenianą?) negatywną kwestią potencjalnych "sesji nocnych" jest fakt że sprawdzamy się "raz dziennie" stąd informacja że sami możemy zarażać nie jest dostarczana natychmiast (tak jak w mojej amatorskiej propozycji - nie to żebym się przy niej upierał ale "dla porównania" raczej ;-) ).

Przy takiej dużej - krajowej a nawet (może docelowo) międzynarodowej skali działań to jest chyba całkiem realny problem, jak uważacie ?

Jest jeszcze jedna - podkreślam czysto teoretyczna kwestia:

Aktualnie rozważamy czyba lokalnie/polskie działanie na serwerze ale przypuszczalnie mogą docelowo pojawić się "europejskie" a nawet "ogólnoświatowe" serwery zbierające wszystkie klucze bo w końcu ludzie zaczną podróżować i świat ustali jakiś poziom "nowej normalności".

Nad tym pracuje inicjatywa https://www.pepp-pt.org/. Z tego co czytałem właśnie rozmawiają (na poziomie europejskim właśnie) z Google + Apple żeby to umożliwić. Rozwiązania jeszcze nie ma ale są różne techniczne możliwości - choćby takie jak docelowe powiązanie tych danych z bardzo, bardzo zgrubnymi danymi dotyczącymi lokalizacji (na przykład na poziomie kraju). Jestem pewien że ponad 130 naukowców i technologów oraz Google + Apple znajdą dobre rozwiązanie.

Artykuł o tym (sprzed 3 dni) poniżej. Ten artykuł mówi co prawda o tym że PEPP-TP i Google + Apple "walczą" i dyskusja jest między "Decentralized" vs. "Anonymous Centralized" ale według mnie rozwiązanie jest "Decentralized with Coarse Location" i tak to się skończy - to dalej może być zdecentralizowane i skalowalne na cały świat.

https://techcrunch.com/2020/04/17/europes-pepp-pt-covid-19-contacts-tracing-standard-push-could-be-squaring-up-for-a-fight-with-apple-and-google/

A nawet przy lokalnym-polskim serwerze z kluczami czy rozważano jakoś teoretycznie jak podobne rozwiązanie będzie stabilne jeżeli powiedzmy 20mln użytkowników "co noc" będzie otwierać sesje celem porównywania swoich kluczy z bazą ?

To już szacowałem tutaj https://github.com/ProteGO-Safe/specs/issues/102#issuecomment-616160642. Wygląda na to (uwaga to jest tzw. po inżyniersku "Back of the envelope calculation") że w Polsce to jest 5.000 nowych kluczy ściąganych codziennie i około 500.000 kluczy do porównania raz dziennie. To są oczywiście szacunki - ale jeśli chodzi o rząd wielkości myślę że to bliskie prawdy. Ściągnięcie raz dziennie 5.000 nowych kluczy (zakładając że każdy ma 32 Bajty) to 160 KB do pobrania. Raz dziennie. W styczniu 2017 średni rozmiar mobilnej strony internetowej (jednej !!!!) to 2.2 MB czyli ponad 15 razy więcej: Źródło: https://www.clickz.com/average-mobile-webpage-is-now-2-2mb-67-is-images-lets-trim-the-fat/109268/ . Więc naprawdę zapas jest spory - nawet gdybyśmy chcieli ściągać cały świat (ale nie musimy - patrz wyżej). Przetworzenie tych 5000 nowych kluczy codziennie (wtedy kiedy telefon jest podłączony do ładowarki) to wygenerowanie ok. 5000 *96 BT Id = ok 500.000 I sprawdzenia czy nie mamy ich w bazie "długich i intensywnych" kontaktów lokalnie. Przy obecnych procesorach (nawet w telefonach starszych niż 4-5 lat) to zadanie na parę minut. Raz dziennie.

Czy to nie jest może jakiś potencjalnie słaby punkt rozwiązania A+G ? Nie jest. Patrz wyżej. Zapewniam że inżynierowie Apple + Google takie obliczenia i weryfikację czy da się to zrobić przeprowadzili jeszcze zanim zostało ogłoszone że "zrobią to". Żaden inżynier o zdrowych zmysłach nie pozwoliłby sobie tu na fuszerkę. A tam pracują jedni z najlepszych.

Wtedy takie "auto-blokowanie" aplikacji przez osoby zdiagnozowane (jesli, tak jak się obawiam będzie ich bardzo dużo...) potencjalnie odciążyłoby system oo stronie serwera, i ta "pauza" dotyczyłaby "porównawczych xsesji nocnych".

Nie ma takiej potrzeby. Z tego co wiem strona serwerowa będzie zaimplementowana za pomocą rozwiązań typu CDN (Content Delivery Network). Każda osoba pobiera co noc dokładnie te same dane. Więc można to wyskalować w nieskończoność praktycznie nie obciążając serwerów. Żródło/informacje: https://cloud.google.com/cdn . Podobne rozwiązanie które wykorzystuje np. Netflix do dystrybucji swoich filmów . W ciągu 4 tygodni wiedżmina obejrzano w 76 milionach domów (https://www.cheatsheet.com/entertainment/the-witcher-this-is-how-many-people-have-already-watched-the-netflix-show.html/). Zakładając że każdy obejrzał 1 odcinek (1h) i że każdy taki film ma 26GB (w rozmiarze 2K) https://filecatalyst.com/how-to-move-large-video-files/ daje to w sumie ~100 PB (!) (100 1024 1024 GB) dziennie dostarczane dla wszystkich na całym świecie (tylko do jednego odcinka jednego serialu). ProteGo musi umożliwić pobranie 30M * 160 K ~ 5 GB dziennie. Około 30 milonów razy (!!!!) mniej niż jeden odcinek Wiedźmina. Naprawdę da się to zrobić. To jest ułamek promila tego co się dzieje obecnie w internecie.

Właśnie sobie uświadomiłem że opisany przeze mnie b.ułomny-amatorski pomysł w #102 jest z założenia pozbawiony jakiejkolwiek możliwości "przeciążania systemu" bo de facto jedyną styczną z systemem jest jednorazowy, jeden SMS :-)

Tylko że ten amatorski sytem nie spełnia podstawowych założeń. A poza tym nie zapomnijmy że tam miały być maile i klucze do weryfikacji - więc nie do końca jest to prawda.

Drugą (niedocenianą?) negatywną kwestią potencjalnych "sesji nocnych" jest fakt że sprawdzamy się "raz dziennie" stąd informacja że sami możemy zarażać nie jest dostarczana natychmiast (tak jak w mojej amatorskiej propozycji - nie to żebym się przy niej upierał ale "dla porównania" raczej ;-) ).

Nie ma takiej potrzeby. Rozdzielczość dzienna jest absolutnie wystarczająca. Człowiek nie zaraża od razu jak zetknął się z chorym. Nawet lepiej jeśli dowie się tego dwa-trzy dni później, bo wtedy jest szansa że testy wykryją wirusa. O ile wiem (może pan @Dr-Kownacki mógłby przytoczyć jakieś wiarygodne źródło w tym temacie, bo pewnie mógłby to zrobić lepiej ode mnie - ja nie jestem w tej dziedzinie specjalistą) wirusa można wykryć dopiero po paru dniach (i można to zrobić zanim osoba zacznie zarażać)

Przy takiej dużej - krajowej a nawet (może docelowo) międzynarodowej skali działań to jest chyba całkiem realny problem, jak uważacie ?

Jak napisałem wyżej - pracują nad tym najtęższe głowy żeby zrobić to dobrze. Rozwiązanie będzie podejrzewam w przeciągu dni lub tygodni.

To wielki przywilej mój dyskutować z profesjonalistami, bardzo dziekuję za tą możliwość. Stąd wytłumaczę mój punkt widzenia odpowiadając/rozwijając @potiuk najlepiej jak potrafię:

1) @@@@ Nie ma takiej potrzeby. Rozdzielczość dzienna jest absolutnie wystarczająca. Człowiek nie zaraża od razu jak zetknął się z chorym. Nawet lepiej jeśli dowie się tego dwa-trzy dni później, bo wtedy jest szansa że testy wykryją wirusa. O ile wiem (może pan @Dr-Kownacki mógłby przytoczyć jakieś wiarygodne źródło w tym temacie, bo pewnie mógłby to zrobić lepiej ode mnie - ja nie jestem w tej dziedzinie specjalistą) wirusa można wykryć dopiero po paru dniach (i można to zrobić zanim osoba zacznie zarażać) @@@@

a) po pierwsze jest korelacja z zaraźliwością a wynikiem testu z uwagi, nie jest ona na pewno prosta do przewidzenia, ale zaobserwowano że jednak czułość tego testu (rt-PCR) jest skorelowana z zaraźliwością a żeby było śmieszniej, jest de facto niższa niż badanie tomografii komputerowej (które jest niestety mniej swoiste stąd ten kij ma dwa końce, ale w Chinach w standardach postępowania jest to uwzględnione) przy objawach klinicznych typu gorączka i brak dodatniego PCR...które wtedy się powtarza i b.często "w końcu" wychodzi ono dodatnie - żaden test nie jest idealny 100% czuły i 100% swoisty...

b) To prawda że "człowiek nie zaraża od razu" ale przyjmijmy że spotkaliśmy kogoś 9 dni temu, kto albo zaczął mieć objawy "następnego dnia" albo po prostu jest "bezobjawowym nosicielem" i informacja o zakażeniu u niego wynikła tylko z przypadkowych okoliczności (bo testy robiono wszystkim w pracy - vide np. szpital gdzie jest ognisko etc.) ten człowiek 9 dni temu już zarażał. Stąd jeżeli my go spotkaliśmy i zaraziliśmy się to jesteśmy albo w okresie inkubacji choroby - zarażamy ale objawy będą dopiero jutro/pojutrze (są różne szacunki nawet +-4 dni ponoć), albo my również będziemy "bezobjawowymi/skąpoobjawowymi nosicielami).

Dzisiaj jest wtorek, minionej nocy z poniedziałku/wtorek moja komórka sprawdziła wszystkie klucze i pokazuje że nie miałem (uchwyconej przez system) ekspozycji.

O 8:00 rano idę więc do pracy na 12 godzinny dyżur (bywają i dłuższe ;-) ), spotykam mnóstwo osób w tym czasie ale już potencjalnie mogę każdego zarazić o czym oczywiście nie wiem.

Natomiast osoba która mnie zaraziła została zdiagnozowana dzisiaj o godz.10:00 i jej klucze zostały wgrane do systemu, jednakże o tym że ja zostałem potencjalnie "trafiony" dowiem się dopiero w nocy z wtorku/środę i dopiero we środę dostanę warning i zacznę się izolować/badać od środy. Stracona została całą doba, i miałem w tym czasie kontakt z 50 osobami. z których część mogłem potencjalnie zarazić.

Przepraszam że wracam do mojego prostego-modelowego pomysłu (tylko celem poglądowym zaznaczam ;-) ), ale gdybym dostał tego "przysłowiowego maila" (lub innego aktywnego warninga) o godz. 10:10, to zrobiłbym od razu test i wyszedłbym z pracy na kwarantannę domową do czasu otrzymania wyniku testu. Nie spotkałbym się przynajmniej z 45 osobami więc nie mógłbym ich potencjalnie zarazić i nie zrobiłbym być może wielu potencjalnie ryzykownych dla pozostałych osób rzeczy.

W pewien sposób pojęcie "fałszywej niezakaźności / fałszywego braku ryzyka" do momentu potwierdzenia - otrzymania dodatniego wyniku testu (w tym przypadku otrzymania "warninga" z aplikacji) byłoby tutaj zgodnie z opisywaną rzekomą sytuacją w szpitalu w Radomiu, gdzie ponoć pracownicy "z kontaktu" pracowali nadal po pobraniu testu i byli odsyłani do izolacji (a nie do kwarantanny wcześniej) dopiero jak otrzymali dodatni wynik testu...

Poza tym jak już we wcześniejszych wątkach wcześniej hipotetycznie postulowałeś, aplikacja byłaby o wiele bardziej ważna/potrzebna w okresie "rozluźnienia obostrzeń" - kiedy byłaby już "nowa normalność" i mniejszy rygor kontaktów, stąd tym bardziej więcej kontaktów można by złapać z tego powodu nich w chwili obecnej.

2) Inny powód dla którego aplikacja mogłaby być "pauzowana" w zakresie "nocnego sprawdzania kluczy" u osób zakażonych ma czysto psychologiczny aspekt: Załóżmy że osoba w szpitalu bądź w izolacji ma rozpoznanie i już wie że jest chora. Natomiast "w międzyczasie" (zanim trafiła do szpitala i miała rozpoznanie) jej aplikacja "nałapała kontaktów" z wieloma osobami które dopiero w kolejnych dniach zostały zdiagnozowane i wysłały klucze na serwer. W ten sposób taki pacjent byłby teoretycznie "nękany złymi informacjami" siłą rzeczy przez aplikację, co zapewniam Was na pewno nie pomoże w powrocie do zdrowia nikomu. Bo każdy chory będzie robił sobie w myślach taki "score" że teoretycznie jak miał 10 kontaktów to jest 10x bardziej narażony np. na zgon niż osoba która miała tylko 1 kontakt... Żeby było jeszcze mniej wesoło, to paradoksalnie może być tutaj nawet trochę racji, jeżeli założymy że te różne osoby mogły mieć różne wirusy z różnymi mutacjami stąd w tej swego rodzaju "rosyjskiej ruletce" przybywa pocisków w komorach rewolweru...

3) Inne wątpliwości ? - być może warte oddzielnego wątku, ale może najpierw skromnie tutaj: W innych wątkach dyskutowaliśmy też o tym czy wymiana "zakażonych" kluczy z serwerem będzie posiadała "znacznik czasowy" - zrozumiałem że wszystko wskazuje na to, że tej informacji dostępnej nie będzie na serwerze powiedzmy najogólniej z przyczyn bezpieczeństwa.

W mojej amatorskiej ocenie w tym systemie byłaby jednak pewna luka związana z możliwością "upload'u kluczy na serwer" mającego miejsce w istotnym opóźnieniu od postawienia rozpoznania że dana osoba jest zainfekoowana.

Prosty/życiowy przykład:

a) pacjent czuje się źle, ma niespecyficzne ale i poważne objawy, stan jest umiarkowanie zły wiec trafia finalnie do szpitala gdzie okazuje się że to zapalenie wyrostka robaczkowego i ma wykonaną operację. Jednocześnie zgodnie z powszechną praktyką pacjentowi wykonuje się test, którego wynik (np. w zerowej dobie po operacji) okazuje się dodatni. W tej sytuacji co do zasady powinno pojawić się działanie w aplikacji, pozwalające na "przesłanie kluczy na serwer". ALE PACJENT ZOSTAWIŁ KOMÓRKĘ W DOMU, zabierało go pogotowie, był w złym stanie etc.

b) Rodzina w 2-giej dobie dostarcza komórkę pacjentowi, znalazła się ładowarka i w końcu np. po 3 dniach od dodatniego wyniku testu te klucze trafiają na serwer z ostatnich 14 dni. Ale w jaki sposób będzie wiadomo, że te klucze są niejako "przeterminowane" ?

Bo przecież nie ma żadnej synchronizacji czasu - skąd więc można wyliczyć że te klucze opublikowane należałoby "3 dni wstecznie" opublikować i skąd aplikacje klienckie podczas "nocnych sesji" wiedziałyby że powinny "cofnąć się w czasie" - jeżeli założymy (jak teoretyzowaliśmy), że te sesje/klucze byłyby teoretycznie "inkrementowo" sprawdzane "za każdy dzień" bez wracania do przeszłości ?

Bo jeżeli założymy że żadne "ramki czasowe" nie trafiają w protokole A+G na serwer (z przyczyn ochrony prywatności) - nawet jeśli są przez aplikację ich "timepointy" odnotowywane to w jaki sposób przekazana byłaby informacja, że chociaż aplikacja osoby która spotkała w/w. pacjenta przed 16 dniami powinna "zawrócić w czasie", jeżeli od momentu upublicznienia klucza minęło ponad 14 dni, ale "de facto" licząc od momentu diagnozy to minęło 12 dni realnie ?

Jeżeli założymy że "wszystko na serwerze starsze niż 14 dni" będzie kasowane (tak ?) żeby uniemożliwiać jakieś metaanalizy etc. to jak powyżej opisaną sytuację można by adresować, skoro żadnej synchronizacji czasu nie będzie (?)

Dodatkowo czy jednak do tych kluczy anonimowych/bez czasu publikowanych na serwerze nie warto byłoby dodawać jakiejś flagi w rodzaju "bezobjawowy nosiciel" albo "kontakt miał pierwsze objawy w dniu 21.04.2020" co znakomicie poprawiłoby szacowanie ryzyk w aplikacji a nawet "ręcznie" przez samego biorcę tych kluczy.

Ten mechanizm mógłby też porządkować kwestie komu należałoby jak najwcześniej (CITO) wykonać test, a u kogo można by kilka dni z tym zaczekać...

Dodatkowo jeżeli my na komórce mielibyśmy lokalnie (bez przekazywania na serwer) oznaczone miejsce z GPS gdzie i kiedy to "spotkanie" nastąpiło, to też byłaby to jakaś pomoc do szacowania własnego ryzyka, kiedy po prostu odkryjemy że o 7:30 to na pewno staliśmy w korku w drodze do pracy i to zagrożenie na pewno nie może być "realne" bo jechaliśmy (staliśmy w korku ;-) ) sami.

Inną być może przydatną opcją w aplikacji byłby też status "mask on / mask off" lokalnie zapisany. Co więcej tako flaga do klucza "zarażającego" też mogłaby być dodawana ponieważ (zgodnie albo pomimo przepisów) będą osoby które masek nie będą miały cały czas na sobie z różnych przyczyn) i to też byłby potencjalnie istotny factor przy oszacowywaniu ryzyka....

Co sądzicie ?

Dzięki bardzo @Dr-Kownacki za merytoryczny wkład od strony diagnozy. Bardzo przydatne i użyteczne.

Stracona została całą doba, i miałem w tym czasie kontakt z 50 osobami. z których część mogłem potencjalnie zarazić.

Jasne. Spoko. nie ma problemu. To rozwiązanie G+A się równie dobrze (a nawet lepiej) skaluje przy sprawdzaniu co godzinę. Odrobinę (pewnie mniej niz 5%) może to wpłynąć na baterię ale liczby są takie:

5000 kluczy/dzień ~ 200 kluczy co godzinę. Co godzinę aplikacja ma do pobranie ~7 KB danych i sprawdzić 200*96 ~ 20.000 kluczy. to zadanie na jakieś 5-10 sekund dla telefonu (z grubsza).
Notyifkacje przychodzą natychmiast jak sprawdzimy. W scenariuszu powyżej zadziała to dokładnie tak samo.

Ściąganie można zrobić co 3 godziny, godzinę, 15 minut , 5 minut - kwestia wypośrodkowania zużycia baterii vs. czas notyfikacji, ale takie sprawdzanie co godzinę praktycznie nie wpływa na baterię (bo i tak co najmniej raz na godzinę ktoś patrzy na telefon - a w obecnych smartfonach najbardziej liczy się czas włączenia ekranu) .

Przepraszam że wracam do mojego prostego-modelowego pomysłu (tylko celem poglądowym zaznaczam ;-) ), ale gdybym dostał tego "przysłowiowego maila" (lub innego aktywnego warninga) o godz. 10:10, to zrobiłbym od razu test i wyszedłbym z pracy na kwarantannę domową do czasu otrzymania wyniku testu.

Tak samo notyfikacja jak wyżej.

Nie spotkałbym się przynajmniej z 45 osobami więc nie mógłbym ich potencjalnie zarazić i nie zrobiłbym być może wielu potencjalnie ryzykownych dla pozostałych osób rzeczy.

Jak wyżej.

Poza tym jak już we wcześniejszych wątkach wcześniej hipotetycznie postulowałeś, aplikacja byłaby o wiele bardziej ważna/potrzebna w okresie "rozluźnienia obostrzeń" - kiedy byłaby już "nowa normalność" i mniejszy rygor kontaktów, stąd tym bardziej więcej kontaktów można by złapać z tego powodu nich w chwili obecnej.

Jak wyżej,

2) Inny powód dla którego aplikacja mogłaby być "pauzowana" w zakresie "nocnego sprawdzania kluczy" u osób zakażonych ma czysto psychologiczny aspekt: Załóżmy że osoba w szpitalu bądź w izolacji ma rozpoznanie i już wie że jest chora. Natomiast "w międzyczasie" (zanim trafiła do szpitala i miała rozpoznanie) jej aplikacja "nałapała kontaktów" z wieloma osobami które dopiero w kolejnych dniach zostały zdiagnozowane i wysłały klucze na serwer. W ten sposób taki pacjent byłby teoretycznie "nękany złymi informacjami" siłą rzeczy przez aplikację, co zapewniam Was na pewno nie pomoże w powrocie do zdrowia nikomu. Bo każdy chory będzie robił sobie w myślach taki "score" że teoretycznie jak miał 10 kontaktów to jest 10x bardziej narażony np. na zgon niż osoba która miała tylko 1 kontakt...

Tu znowu niezrozumienie co znaczy "pauzowanie". Nie mówiłem nic o nękaniu i notyfikacjach, tylko o działaniu BT/LE i zbieraniu danych. Jeśli ktoś jest "zdiagnozowany" jego status powinien się zmienić na .... zdiagonozowany właśnie. A dopiero kolejna diagnoza powinna móc to zmienić (z odpowiednim kodem). Zbierać informację można dalej i lekarz - w sytuacjach o których pisałem - może zdecydować o ponownym wysłaniu x ostatnich dni na serwer. Ale to nie ma nic wspólnego z notyfikacjami w aplikacji. Nie ma żadnej potrzeby żeby osoba zdiagnozowana jako chora powinna dostawać notyfikacje i to powinno wynikać ze statusu tej osoby. Ale to nie ma nic wspólnego z protokołem BT, rozgłaszaniem i zbieraniem informacji. To powinno działać cały czas.

Żeby było jeszcze mniej wesoło, to paradoksalnie może być tutaj nawet trochę racji, jeżeli założymy że te różne osoby mogły mieć różne wirusy z różnymi mutacjami stąd w tej swego rodzaju "rosyjskiej ruletce" przybywa pocisków w komorach rewolweru...

Tak daleko na pewno aplikacja nie będzie wchodzić. Diagnoza który szczep wirusa wchodzi w grę jest chyba bardzo trudna w dużej skali i niepotrzebna skoro i tak nie wiemy jak to wpływa na zarażalność,

W mojej amatorskiej ocenie w tym systemie byłaby jednak pewna luka związana z możliwością "upload'u kluczy na serwer" mającego miejsce w istotnym opóźnieniu od postawienia rozpoznania że dana osoba jest zainfekoowana.

W protokole A + G na serwer zawsze uploadowane są "Diagnosis Keys" - czyli para (Dzień + Daily Trackin Seed). Nic mniej, nic więcej. I to jest bardzo dobry pomysł,

Prosty/życiowy przykład:

a) pacjent czuje się źle, ma niespecyficzne ale i poważne objawy, stan jest umiarkowanie zły wiec trafia finalnie do szpitala gdzie okazuje się że to zapalenie wyrostka robaczkowego i ma wykonaną operację. Jednocześnie zgodnie z powszechną praktyką pacjentowi wykonuje się test, którego wynik (np. w zerowej dobie po operacji) okazuje się dodatni. W tej sytuacji co do zasady powinno pojawić się działanie w aplikacji, pozwalające na "przesłanie kluczy na serwer". ALE PACJENT ZOSTAWIŁ KOMÓRKĘ W DOMU, zabierało go pogotowie, był w złym stanie etc.

Trudno, świetnie, Prosimy jego rodzinę o przywiezienie komórki, Zupełnie serio - ile razy zdarzyło się zapomnieć komórki w domu? Nie mam wiarygodnych statystycznych źródeł na ten temat, ale mi się w ciągu roku zdarzyło 2 razy (<1%, czyli w 99% miałem telefon ze sobą). Wszelkie źródłą na temat contact tracing mówią że ma to sens jak nasycenie jest > 60% .. Zostawiam statystykę do samo-oceny i wyciągnięcia wniosków.

b) Rodzina w 2-giej dobie dostarcza komórkę pacjentowi, znalazła się ładowarka i w końcu np. po 3 dniach od dodatniego wyniku testu te klucze trafiają na serwer z ostatnich 14 dni. Ale w jaki sposób będzie wiadomo, że te klucze są niejako "przeterminowane" ?

Kod do wysłania danych powinien określać ile dni wstecz obejmuje. A może nawet które konkretnie dni. "Diagnosis Key = DST + dzień w którym DST jest wżny. Wszystkie klucze DST mają przypisany konkretny dzień w którym były "aktywne". Wysłanie DST ze złym dniem jest niemożliwe.

Bo przecież nie ma żadnej synchronizacji czasu - skąd więc można wyliczyć że te klucze opublikowane należałoby "3 dni wstecznie" opublikować i skąd aplikacje klienckie podczas "nocnych sesji" wiedziałyby że powinny "cofnąć się w czasie" - jeżeli założymy (jak teoretyzowaliśmy), że te sesje/klucze byłyby teoretycznie "inkrementowo" sprawdzane "za każdy dzień" bez wracania do przeszłości ?

Błąd logiczy, W protokole G+A Diagnosis Key = DST+ dzień ważności tego klucza. Pewnie można by to próbować oszukać ręcznie zmieniając datę w telefonie, ale to nic nie daje "trollom" G+A mogą zaimplementować w protokole odrucanie takich błędnych "advertisments" - choćby w taki sposób że będą sprawdzać czy data jest ok tuż przed "BT broadcast". Wydaje się, że nie da się tego oszukać. ale chętnie posłucham konkretnych scenariuszy jak można by. Każda praktycznie komórka ma wbudowana synchdonizację czasu włączoną automatycznie (synchronizacja nastąpiła za pomocą protokołu GSM i wystarczy do tego połączenie mobilne z internetem. Kiedy ostatni raz musiałeś ustawiać czas w swoim telefonie ? Czas jest trudny do regulacji w urządzeniach nie podłączonych do internetu bez specjalistycznych urządzeń i kalibracji (jak w zegarkach szwajcarskich) - gdyby nie było synchronizacji, czas rozjeźdzał by się regularnie i np. telefon w komórce spóźniałby się codziennie o parę minut. Tak się nie dzieje i pewnie nie pamiętasz ostatnio kiedy samodzielnie zmieniałeś czas w komórce - łącznie z zmianą czasu na letni/zimowy.

Bo jeżeli założymy że żadne "ramki czasowe" nie trafiają w protokole A+G na serwer (z przyczyn ochrony prywatności) - nawet jeśli są przez aplikację ich "timepointy" odnotowywane to w jaki sposób przekazana byłaby informacja, że chociaż aplikacja osoby która spotkała w/w. pacjenta przed 16 dniami powinna "zawrócić w czasie", jeżeli od momentu upublicznienia klucza minęło ponad 14 dni, ale "de facto" licząc od momentu diagnozy to minęło 12 dni realnie ?

Powtórzę jescze raz, Każdy raport osoby zdiagnozowanej to Diagnosis Key - datat (dzień) kiedy był ważny + unikalny DST ID. Z tego każdy kto go dostanie może obliczyć wszystkie 96 BT tracking id i okreśłić z lokalnej bazy czy jest się czym przejmować.

Jeżeli założymy że "wszystko na serwerze starsze niż 14 dni" będzie kasowane (tak ?) żeby uniemożliwiać jakieś metaanalizy etc. to jak powyżej opisaną sytuację można by adresować, skoro żadnej synchronizacji czasu nie będzie (?)

Będzie na poziomie 1 dnia, Patrz wyżej

Dodatkowo czy jednak do tych kluczy anonimowych/bez czasu publikowanych na serwerze nie warto byłoby dodawać jakiejś flagi w rodzaju "bezobjawowy nosiciel" albo "kontakt miał pierwsze objawy w dniu 21.04.2020" co znakomicie poprawiłoby szacowanie ryzyk w aplikacji a nawet "ręcznie" przez samego biorcę tych kluczy.

Przy uploadzie mówimy "Ten DST w tym konkretnie dniu zarażał". Na lekarzu spoczywa odpowiedzialność żeby odpowiednio zdecydować które z ostatnich 14 dni osoby są "zarażające". Duża odpowiedzialność a jednocześnie "Human in the loop".

Ten mechanizm mógłby też porządkować kwestie komu należałoby jak najwcześniej (CITO) wykonać test, a u kogo można by kilka dni z tym zaczekać...

To juś niech GIS decyduje na temat wywiadu/anych z aplikacji. Aplikacja tylko dostarcza danych.

Dodatkowo jeżeli my na komórce mielibyśmy lokalnie (bez przekazywania na serwer) oznaczone miejsce z GPS gdzie i kiedy to "spotkanie" nastąpiło, to też byłaby to jakaś pomoc do szacowania własnego ryzyka, kiedy po prostu odkryjemy że o 7:30 to na pewno staliśmy w korku w drodze do pracy i to zagrożenie na pewno nie może być "realne" bo jechaliśmy (staliśmy w korku ;-) ) sami.

Do tego nie potrzeba GPS. Pisałem już o tym wcześniej. Współczesne teleony mają możliwość określenia co ktoś robi (jedzie rowerem, autobusem, samochodem. biegnie, idzie, stoi) bez konieczności używania GPS. I to powinno być częścią apki.

Inną być może przydatną opcją w aplikacji byłby też status "mask on / mask off" lokalnie zapisany. Co więcej tako flaga do klucza "zarażającego" też mogłaby być dodawana ponieważ (zgodnie albo pomimo przepisów) będą osoby które masek nie będą miały cały czas na sobie z różnych przyczyn) i to też byłby potencjalnie istotny factor przy oszacowywaniu ryzyka....

Zasadą powinno być, że system powinien sam działać w tlle, bez żadnej interakcji użytkownika, Z zasady - po włączeniu system powinien działać sam. Nie ma żadnych mechnamizmów które pozwolą nadzorować tto czy maska jest on czy off. Nie wiemy jaka to maska, czy jest dobrze założona (dziś widziałem gościa z maską na szyi). Podstawą tej części działania systemu jest że będzie działać automatycznie bez udziału użytkownika.

Załóżmy że wszytko jest OK technicznie i użytkowo, ProteGO śmiga na API A+G, a aplikacji używa w Polsce prawie każdy.

Pojawiają się jednak zagadnienia do przemyślenia workfkow i pewnie warto takie możliwości przedyskutować np.:

Pacjent zdiagnozowany, logi tracingu opublikowane do centralnej bazy poprzez autoryzację aplikacji przez rządowy serwer: a) czy aplikacja automatycznie powinna zostać następnie "auto-zablokowana" po przesłaniu tych logów czy nie ?

b) jeżeli powinna być blokowania to na jak długo ? 14 dni? O tej chorobie nadal wielu rzeczy nie wiemy w kwestii nabycia odporności więc nie można założyć że przechorowanie załatwia sprawę.

c) a może do momentu uzyskania statusu "ozdrowieńca" - zatem powinien istnieć jakiś mechanizm "odblokowania aplikacji" jeżeli istniałby mechanizm jej auto-blokowania ? Rozumiem że status chorego zmieniany na zdrowego musiałby realizować ten sam serwer GIS/MZ, który przechowuje te centralne dane (ogłaszane łącznie codziennie).

Jeżeli aplikację zablokujemy i pacjent:

a) trafia do szpitala to "odpowiedzialność za jego izolację" spada na służbę zdrowia, bo wiadomo że jest chory - aplikacja wyłączona. Jeżeli nie byłaby wyłączona to wiadomo że telefony personelu będą "łapać" ciągle te logi i na pewno wiele osób zapomni apke w pracy wyłączyć (tutaj od razu pomysł na auto-pause po GPS w ustawieniach użytkownika dla danego obszaru/rejonu).

b) nie ma poważnych objawów to trafia do izolacji domowej to czy wtedy przy wyłączonym odgórnie ProteGo powinien mieć obligatoryjnie włączoną aplikację a'la "Kwarantanna Domowa" (jakaś "Izolacja Domowa"?)

c) w trybie b) nie zastosuje się do izolacji i "ruszy w miasto" (z telefonem) to czy jednak dla dobra społecznego ProteGo nie powinno być jednak bez dezaktywacji dla osób w izolacji "domowej" ?

d) jeżeli zostałoby popełnione przestępstwo c) to wtedy musiałby istnieć obligatoryjny mechanizm "ponownego opublikowania kluczy", ale jak ten proces katalizowac ? GIS ? Policja ?

e) jeżeli na izolacji domowej nawet złapie sąsiada w bloku przypadkiem przez drzwi to i tak nie będzie miał w jaki sposób skatalizować opublikowania logu i niby nie ma problemu...

f) ... ale d) spowoduje ponowne rozesłanie kluczy nawet dla sytuacji e) niestety

Czyli na BT się nie skończyło (mowa o GPS) i będzie to kolejna wersja "Kwarantanny Domowej" #53. Bardzo nieładnie. @MinisterstwoCyfryzacji Znów zmusicie użytkowników do wysyłania swoich zdjęć na serwer?

@All: możecie ze swoich telefonów wymontować BT, a kamerkę można załatwić gwoździem (najprostrzy sposób) lub też wymontować z telefonu lub wewnętrznie zakleić obiektyw.

Aplikacja poza tym wygląda w myśl licencji GPL jak nakładka. Sama w sobie bez użycia interfejsu Google/Apple nie będzie potrafiła działać. Taki GPL to nie jest GPL!

@SeraMoon ponieważ jestem łącznikiem z MC i MC poprosiło nasz zespół o wdrożenie aplikacji na skalę ogólnopolską, posiadam najbardziej aktualną wiedzę o projekcie i nie ma w niej nic co pojawiło się powyżej. Pojawiają się tutaj opinie nie poparte faktami. Dodatkowo, na GH nie ma ludzi z MC tylko są ludzie, którzy zostali poproszeni MC o wykonanie aplikacji. Więc z najlepszą wiedzą jaką mam odpowiem na każde pytanie. Co więcej, nie jesteśmy anonimowi, odpowiadamy własnymi nazwiskami a także firmami za to co robimy i mówimy.

Nie ma żadnego wątku GPS w aplikacji
Nie ma żadnego wątku zdjęć
Nic nie jest auto-przesyłane na serwer (logi spotkanych TempID są zapisywane lokalnie, to user samodzielnie, po kontakcie z GIS może je wysłać jeżeli chce żeby inne aplikacje dostały informację że widziały się z aplikacją, której użytkownik był chory na COVID-19 w momencie spotkania)
TempID rotuje się co 15 min
Nikt nie jest w stanie zrobić takiej skali jak G&A a bez skali nie jest możliwe: a. odmrażanie gospodarek, b. mitygacja ryzyka zarażeniem.

Nikt nie jest w stanie zrobić takiej skali jak G&A a bez skali nie jest możliwe: a. odmrażanie gospodarek, b. mitygacja ryzyka zarażeniem.

Jak zatem będzie wyglądało obsługiwanie ludzi, którzy nie mają odpowiedniego telefonu, aby zainstalować aplikację? Czy będą dyskryminowane przez rząd lub pracowników firm?

Wciąż będą ludzie:

z telefonami z innym systemem operacyjnym,
bez telefonu,
z telefonem z przyciskami fizycznymi, gdzie nie jest możliwa obsługa aplikacji (takie najczęściej też nie mają androida ani iOS),
będą tutaj też bezdomni, którzy prawie zawsze nie mają telefonu.

ponieważ jestem łącznikiem z MC i MC

@MateuszRomanow czy możesz zapewnić tutejszą społeczność i ludzi, którzy publicznie czytają te wątki, że MC nigdy nie zamierza tych osób dyskryminować o to, że nie mają aplikacji?

@SeraMoon z całym szacunkiem, ale nie jestem rzecznikiem ani pracownikiem MC więc nie mi takie zapewnienia dawać. To co jestem w stanie zapewnić, to że w kontakcie i rozmowach, w których ja brałem i biorę udział taki wątek nigdy nie miał miejsca, i stanowisko obu stron zawsze było i jest jedno - brak jakiejkolwiek dyskryminacji. Więcej tutaj #106

Z powodu dłuższej nieaktywności w tym wątku, zostanie on automatycznie zamknięty w najbliższym czasie.

Jeżeli ktoś ma coś przeciwko to niech da znać, lub założy wątek zgodny z obecnymi założeniami

ProteGO-Safe / specs

PACJENT "ZAKAŻONY": co dalej z jego Appką, " PAUZA" ? #107