Aplikacja na telefonach personelu medycznego

[nuschpl]

Był temat tego co sie ma dziać z aplikacją po wykryciu a ja mam kolejny edge case - jak traktować aplikacją telefony pielęgniarek i lekarzy - którzy mogą być metr od osoby zarażonej długi czas w kombinezonie ale instaluja aplikacje żeby chronić się w życiu prywatnym. Być może przydałby się jednak odwrotność zaznaczania statusu jako chorego przez uprawnione jednostki - tak żeby taki lekarz mimo ekspozycji mógł regularnie resetować swój status do zdrowego . Z jakimś poziomem ryzyka aplikacja powinna raportować jego znajomym bo jednak jest w grupie podwyższonego ryzyka ale nie powinna ustawiać statusu - na 90% zarażony tylko dlatego że taki lekarz ma ekspozycje większą niż reszta społeczeństwa.

[SeraMoon]

Przeciw. Sytuacja roznoszenia się zakażeń w szpitalach i DPS-ach (w obu miejscach są lekarze i pielęgniarki) pokazuje, że "przyczyną" dużej ilości zakażeń są właśnie lekarze (i pielęgniarki). Nie to, że chcę tu potępić tą grupę, bo jest zupełnie inaczej, gdy walczą o zdrowie kowidków, ale niestety właśnie oni są najbardziej narażeni na zakażenie (i dalsze zarażanie innych) poprzez:

• wadliwy sporzęt ochronny (maski okazują się nie mieć atestów),
• maski nawet te z filtrami przepuszczają wirusy w niewielkim ale przy pracy 8h w zakażonym miejscu - w znacznym stopniu,
• są niestety bliżej chorego niż bezpieczny 4-8m dystans,
• w odległości 1m jest jeszcze aerozol chorego zawierający najdrobniejsze cząstki, które maski (nawet te N99) słabo łapią.

Nie widzę więc powodu, aby lekarzom dawać możliwość czyszczenia statusu. Wyczyścić powinni móc jak każdy obywatel - po teście potwierdzającym brak zakażenia (powtórzonym wg wytycznych WHO).

Edit: czytałam jakiś czas temu, że przy obsłudze pacjentów w którymś kraju (nie przywołam z pamięci) pomagają roboty - nawet przynosząc choremu leki. Celem jest właśnie zmniejszenie ekspozycji lekarzy. Taką technologię uważam za pożyteczną - robot który jest odporny na wirusa zastępuje czasowo a nie całkowivie człowieka - w miejscu dla człowieka niebezpiecznym.

Kiedy takie roboty rząd sprowadzi do Polski celem zabezpieczenia lekarzy przy części pacjentów, którzy mogą leki czy posiłek odebrać od robota? Podobne roboty obsługują też niektóre lotniska - od lat wyręczając personel...

[KoderFPV]

@SeraMoon Wydaje mi się że tylko Health Authority będzie miał możliwość czyszczenia statusu. Takie są założenia projektowe w przypadku wykorzystania obecnego Open Trace oraz przyszłego rozwiązania G+A.

I od razu przestrzegam przed spamowaniem w tym wątku na temat zmian projektowych. Posty odbiegające od tematu mogą zostać ukryte, a wątek nawet zamknięty.

Ten wątek dotyczy tylko i wyłącznie czy lekarze będą mogli sami czyścić status.

@nuschpl Skoro to Health Authority będzie mogł czyscić status, to czy to nie wystarcza? Lekarze będą mogli być (i powinni!) w stałym kontakcie z osobami do tego uprawnionymi.

@SeraMoon Zanim skończyłem pisać tego posta, już zaczęłaś zmieniać wątek na temat sprowadzania robotów do polski! Prosimy trzymać się tematu!

[jasisz]

Nie wiem jak w rozwiązaniu ProteGO Safe (tej części chyba jeszcze nie ma), ale w innych rozwiązaniach jest możliwość "wyłączenia" części spotkań podczas procesu uploadowania historii swoich spotkań. Spotkania w szpitalu mogłyby zwyczajnie nie być rozgłaszane.

[KoderFPV]

@jasisz Napewno jeszcze takiej funkcjonalności nie ma. Ale wydaje się że może się ona przydać. To moja prywatna opinia :)

[SeraMoon]

I od razu przestrzegam przed spamowaniem w tym wątku na temat zmian projektowych. Posty odbiegające od tematu mogą zostać ukryte, a wątek nawet zamknięty.

@potiuk, czy ciągłe oskarżanie o spam jest zgodne z CoC CNCF zaś "ukrywanie" postów nie jest próbą manipulacji dyskusją? Wyrazisz swoje zdanie w tym lub nowym wątku?

[qLb]

Z dokumentacji G+A Exposure Notification API v1.2 April 30 2020

The following diagram illustrates the data structure and formula used to calculate theExposure Risk Level.

The ​ExposureConfiguration​ class contains fields that your app can pass in to theStart​ method:

• minimumRiskScore​, an integer value between 1 and 8 that specifies how strong a calculated risk needs to be in order to be recorded.
• attenuationScores​, an array in which you specify how much risk to associate with the Bluetooth attenuation value from an exposure. These values are multiplied by the value of the ​attenuationWeight​ field to determine a value foreach range.
• daysSinceLastExposureScores​, an array in which you specify how much risk to associate to an exposure based on the number of days since the exposure happened. These values are multiplied by the value of thedaysSinceLastExposureWeight​ field to determine a value for each range.
• durationScores​, an array in which you specify how much risk to associate with an exposure based on the duration of the exposure. These values are multiplied by the value of the ​durationWeight​ field to determine a value for each range.
• transmissionRiskScores​, an array of custom values that specify how much risk to associate with a risk factor you designate. For example, you might associate the Highest Risk value with a user who has recently tested positive,and the Medium Risk for a user who came into contact with apositively-diagnosed person. These values are multiplied by the value of thetransmissionRiskWeight​ field to determine a final value for eachtransmissionRiskScores​ value.

These fields are used in the following calculation to determine a ​RiskScore​, which must exceed the ​minimumRiskScore​ value, for the exposure to be recorded:

RiskSum​ = (​attenuationScore​ * ​attenuationWeight​) +(​daysSinceLastExposureScore​ * ​daysSinceLastExposureWeight​) +(​durationScore​ * ​durationWeight​) + (​transmissionRiskScore​ *transmissionRiskWeight​)

RiskScore​ = ​RiskSum​ / (​attenuationWeight​ + ​daysSinceLastExposureWeight​ +durationWeight​ + ​transmissionRiskWeight​)

Zgodnie z tymi wytycznymi mozliwe jest by oslabiac wynik oceny ryzyka dla personelu medycznego podajac w ich aplikacji lokalnie odpowiednia wartosc ​attenuationScore i/lub ​attenuationWeight​. Nie wiemy jak wyglada treshhold i nie bedziemy wiedziec do momentu faktycznej implementacji wszystkich metod w G+A Exposure Notification API.

Dodam, ze Twoje pytanie @nuschpl jest naszym wspolnym i prosze Cie bys zadal je w przejrzysty sposob w #134

[potiuk]

I od razu przestrzegam przed spamowaniem w tym wątku na temat zmian projektowych. Posty odbiegające od tematu mogą zostać ukryte, a wątek nawet zamknięty.

@potiuk, czy ciągłe oskarżanie o spam jest zgodne z CoC CNCF zaś "ukrywanie" postów nie jest próbą manipulacji dyskusją? Wyrazisz swoje zdanie w tym lub nowym wątku?

Myślę faktycznie trzymanie się wątku jest ważne. Dobrze że twórcy zmieniają podejście i staraja się odpowiadać na zadane pytania (do tej pory tego nie było) i starają się pilnować trzymania tematu. Myśłę że tak naprawdę wszystkim nam zależy żeby docelowo ratować ludzkie życie (z poszanowaniem prywatności). Mi zależy i na jednym i na drugim.

Doceniam to @qlb i @Tarvald że staracie się odpisywać. Natomiast dobrze by było (gwoli transparentności) nie zamykać issuesów które nie są jeszcze rozwiązane tak jak to opisałem w #142. Apeluję o to aby przynajmniej to zbiorcze issue otworzyć - to może pokazać że faktycznie chcecie się otworzyć na dyskusję i zmienić sposób działania w projekcie. I nie mam nic przeciwko żeby oznaczyć ten wpis jako off-topic jeśli tylko apel w nim zawarty zostanie rozważony i wysłuchany. Jeśli chcecie współpracy, to proszę - też współpracujcie. Ja naprawdę chętnie pomogę i będę mocno kibicował, jeśli to będzie otwarty i dobry projekt.

[KoderFPV]

@nuschpl Czy @qLb odpowiedział na twój problem, czy można zamknąć temat?

[Dr-Kownacki]

Dodam że szczerze wątpię aby;

a) ktoś z telefonem /swoim-codziennym/ przy "realnej obsłudze" tych pacjentów chodził bo ma kombinezon i maskę (pełną) pewnie zwykle - czyli taką w której może nie dać się rozmawiać...Zakładam raczej łączność innego rodzaju bo zestawy "a'la laryngofon" do komórki to chyba margines... chociaż wykonalny :-) Jeżeli maska jest typu "wojskowego" to ma komorę fonacyjną (widać ją np. na moim awatarze ;-) ) więc ew. tryb głośnomówiący zostaje też ewentualnie...

Ponadto:

b) Ta "ekspozycja" nawet gdyby ktoś miał telefon w kieszeni to na oddziale z chorymi i tak nie zadziała, z przyczyn logicznych przestawionych w #107 - nie będzie "wgrywania kluczy pacjentów" raczej podczas pobytu na oddziale bo już zostały wgrane przy przyjęciu.

c) Aplikacja z założenia ma wskazywać "nieuświadomione" kontakty i ostrzegać - natomiast jak ktoś pracuje w warunkach oddziału zakaźnego to jest "uświadomiony" kontakt wiec na zakaźnym oddziale nie ma to sensu. Aktualnie nie ma żadnych limitów w dostępie do badań (PCR) personelu medycznego, wszystko i wszędzie jest w pełni refundowane

d) Jeżeli nawet byłoby inaczej i taki scenariusz mógłby mieć miejsce to i tak można "zapauzowac" aplikację albo BT bo ona ma inną funkcję przecież, stąd nie byłby to realny problem.

e) Potrzebę funkcji/wersji aplikacji "dla medyków" od dawna tu postuluję m.in. w #63 W jednym z wątków wykazałem nawet arytmetycznie że (na ówczesne dane) aplikacja "dla medyków" jest ok.19x bardziej potrzebna niż "aplikacja dla wszystkich".

Postulowalem zastosowanie QR kodów do powiedzenia "pewnych" np. zawodowych kontaktów pomiędzy personelem medycznym w pracy (i nie tylko medycznym, to się "wszędzie" przydać może).

Jakieś echa tego QR-pomyslu są w planowanej iteracji dla ProteGo Safe "zakres 3.1" chyba ( ,https://github.com/ProteGO-Safe/specs/blob/master/README.md ), ale to oddzielny temat niż to co proponowałem w #108 i absolutnie nie łączę tego ze słynnymi już "galeriami handlowymi" ;-)

[miklobit]

Lekarz nie musi niczego resetować bo przecież dopóki nie jest pozytywnie zdiagnozowany to zakładamy że jest zdrowy i nie ma żadnego "zagrożenia" dla jego kontaktów BT że dostaną fałszywie pozytywny sygnał o możliwym kontakcie z zakażonym. Temat śledzenia kontaktów wewnątrz placówek służby zdrowia / DPS'ów itp wg mnie wykracza poza kwestię tylko aplikacji choćby z powodów wymienionych wyżej - noszenie i używanie telefonu jest dość uciążliwe w sprzęcie ochronnym. Prawdopodobnie ten temat powinien być "ogarnięty" nie aplikacją na tel tylko dedykowanymi urzadzeniami w rodzaju opaski BT - zakładane tylko na czas przebywania w placówce wszystkim przebywającym tam osobom (personelowi, chorym , osobom pod obserwacją itd), To jednocześnie rozwiązuje kwestie sprzętowe (np. długi czas pracy na baterii,) oraz upraszcza kwestie ochrony danych osobowych - bo urządzenia w ogóle nie miałoby (samodzielnego) dostępu do internetu.

[Dr-Kownacki]

Odświeżę, że "sprzętowe pomysły" omawiamy tutaj: #101 i jest to bardzo słuszna uwaga, tym bardziej że:

https://www.bbc.com/news/technology-52409893 Cyt.: Some researchers suggest simple Bluetooth wristbands could be used by people who do not own a smartphone. "It would be an option to increase coverage and there are also cheaper Bluetooth devices that could have the basic functionality without being a full smartphone," said Christophe Fraser from the Oxford Big Data Institute.

"Wearable Bluetooth devices could indicate in a very basic way whether contact has been made."

[pkleczko]

w związku z brakiem aktywności w wątku pozwolę sobie go zamknąć.