Aktualne grafy lub opisy decyzyjne WHO i CDC

[SeraMoon]

Is your feature request related to a problem? Please describe.

161

Describe the solution you'd like @porz Proszę o linki do tych wytycznych CDC i WHO, na bazie których powstał przedstawiony (w podglądzie nieczytelny) graf decyzyjny - przydałby się też jego eksport do SVG lub innego formatu, gdzie można przeczytać tekst.

Planuję ze znajomymi wykonać aplikację internetową, która przeprowadzi test ryzyka w oparciu o sam JavaScript bez pobrania innych danych poza zasobami (1 plik z grafikami, treść CSS, JS i HTML), jako że wszystko co dotyczy koronawirusa powinno być otwarte i powinniśmy się tą wiedzą dzielić.

Describe alternatives you've considered -

Additional context @porz

[porz]

Oczywiście - dzielę się publicznie dostępną dokumentacją. Linki do źródeł i krótki opis znajdują się tutaj: https://developer.infermedica.com/docs/covid-19#medical-foundations

https://www.who.int/emergencies/diseases/novel-coronavirus-2019/situation-reports/ https://www.cdc.gov/coronavirus/2019-ncov/community/home/index.html https://www.cdc.gov/coronavirus/2019-ncov/if-you-are-sick/steps-when-sick.html https://www.cdc.gov/coronavirus/2019-ncov/php/risk-assessment.html https://www.cdc.gov/coronavirus/2019-ncov/travelers/after-travel-precautions.html

Tutaj załączam też spakowany plik SVG, aby było wygodniej: Infermedica COVID-19 Risk Assessment flow.zip

Kilka punktów dla tworzących tego rodzaju aplikację:

• Drzewo może się zmienić w każdej chwili, więc synchronizacja może być wyzwaniem.
• Kontent dostarczamy "as is" - nie ponosimy żadnej odpowiedzialności za aplikację, którą Ty stworzysz lub będziesz dystrybuować.
• Korzystanie z publicznych informacji nie upoważnia do korzystania z nazwy firmy Infermedica w jakikolwiek sposób bez naszej zgody. Nie endorsujemy Twojego projektu, ale oczywście trzymam kciuki, bo każda inicjatywa w tym trudnym czasie jest potrzebna.

Pozdrawiam serdecznie

[SeraMoon]

Dziękuję Panu serdecznie :)

Drzewo może się zmienić w każdej chwili, więc synchronizacja może być wyzwaniem.

Właśnie dlatego potrzebuję tych wytycznych WHO i CDC aby móc śledzić je botem po stronie serwera lub u mnie lokalnie i abym mogła podmieniać JavaScript w aplikacji oceniającej. W pełni prywatnie i bezpiecznie dla użytkownika 😸

Szkoda, że do tych dokumentów jest tak trudno trafić - one powinny być na stronie głównej CDC i WHO - jeżeli ten wirus stanowi zagrożenie większe lub równe grypie.

Niemniej jeszcze raz dziękuję.

[qLb]

Wydaje sie, ze dostala Pani wszystko czego oczekiwala. @SeraMoon zamykam zatem i uwazam za rozwiazane.

[SeraMoon]

@porz plik zip z SVG jest uszkodzony. Zawiera nie te pliki, które powinien.

Edit - nie wymaga re-otwarcia: Udało się otworzyć plik v4.vnd.jgraph.mxfile

[porz]

OK - to co przypadkiem spakowałem wcześniej to plik dla https://www.diagrams.net/ Teraz załączam plik SVG. Sorry za pomyłkę.

Infermedica COVID-19 Risk Assessment flow.svg.zip

[SeraMoon]

Korzystanie z publicznych informacji nie upoważnia do korzystania z nazwy firmy Infermedica w jakikolwiek sposób bez naszej zgody.

OK. Nie będziemy wspominać nazwy Pana firmy. Postaram się w pierwszej kolejności zapoznać z dokumentami dostarczonymi przez CDC i WHO i jedynie na nie się powołamy. Graf jednak przyda się do przyjrzenia się samej ocenie i powiązaniu informacji z oficjalnych dokumentów WHO/CDC.

Kontent dostarczamy "as is" - nie ponosimy żadnej odpowiedzialności za aplikację, którą Ty stworzysz lub będziesz dystrybuować.

Rozumiem, toteż przeprowadzimy audyt grafu jako początkowy element działania w oparciu o dokumentację WHO i CDC. Zastanowimy się też jak na bieżąco w miarę automatycznie lub półautomatycznie dokonywać update JavaScriptu odpowiedzialnego za ocenę stanu ryzyka zakażenia COVID-19.

[potiuk]

Faktycznie nie wygląda to na "rocket science". Jest pewnie mnóstwo rozwiązań, które to pozwolą w offline zrobić w javascripcie choćby - faktycznie. Trochę dziwne, że PrroteGO wybiera do tego darmowy serwis, który nie daje żadnej gwarancji działania, nie daje wsparcia i może być w każdj chwili wyłączony. Jeśli to prawda, że budżet projektu jest siedmiocyfrowy a potencjalnie ma z tego korzystać parę milionów osób, to naprawdę dziwny wybór.

[qLb]

Widze, ze jeszcze sa jakies watpliwosci. Otwieram wiec i prosze autora (@SeraMoon) o zamkniecie w chwili ich wyjasnienia.

[jasisz]

@porz Pełen szacuneczek za oświadczenie, którego niestety nie można skomentować.

[porz]

@porz Pełen szacuneczek za oświadczenie, którego niestety nie można skomentować.

Panie Szymonie - nie jestem ekspertem GitHuba, ale jak można łatwo zauważyć w tamtym wątku to zgłoszenie zamknął moderator a nie ja:

ProteGO-Safe locked as too heated and limited conversation to collaborators

Jeżeli miałby Pan do mnie jakieś pytania - zapraszam.

[Dr-Kownacki]

@porz z pozdrowieniami i dedykacją od doktora ;-)

https://github.com/ProteGO-Safe/specs/issues/127#issuecomment-622373788

[SeraMoon]

Eh, a mówiono, że nie da się tej części zastąpić javascriptem, bo po drugiej stronie siedzi "sztuczna inteligencja" (AI). Szkoda, że te wszystkie twierdzenia idą z kapelusza a nie poprzez konsultację z podmiotami i osobami odpowiedzialnymi - choćby przez zapytanie firmy, audyt zewnętrzny (polecam Niebezpiecznik i Zaufaną Trzecią Stronę). Nie wpływa to dobrze na zaufanie, ale przeniesienie podejmowania decyzji o oznaczeniu jako zielony / czerwony / pomarańczowy (o ile taki status jest) pozwoli spełnić lepiej #129 (7 filarów zaufania)

@qLb, jeżeli uważasz, że inni swoje wątpliwości wyjaśnili - czuj się wolny zamknąć ten wątek (jednak dalej widzę przybywające wypowiedzi). Teraz należałoby otworzyć kolejny, podać grafy (które powinniśmy sami na nowo stworzyć na podstawie CDC i WHO) i zlecić do implementacji ocenę zdrowia offline - będzie przy okazji dostępne zawsze a nie tylko online, skończą się problemy z Cloudflare, VPN-ami i cała resztą - w aplikacji smartfonowej (problemy będą dotyczyć nadal wersji Web).

Edit: wątek pod implementację - dodany.

[porz]

@Dr-Kownacki dziękuję i również pozdrawiam :)

#127 (comment)

Bardzo szanuję punkt widzenia i super, że myślisz o innych. Tymczasem my naprawdę nie mamy jakichkolwiek oczekiwań finansowych. Jeśli ProteGO ma ujrzeć światło dzienne i dotrzeć do wielu ludzi w Polsce, to z samego poczucia obowiązku doradzimy jak zaimplementować nasze drzewa bez jakiejkolwiek komunikacji z serwerem.

W tej całej sprawie martwi mnie po prostu stawianie naszej firmy w jakimś "niedopowiedzianym kontekście spiskowym", bo ani nie jesteśmy autorem projektu ProteGO ani na to nie zasłużyliśmy moim zdaniem. Jeżeli przetwarzanie offline jest metodą, możemy pomyśleć o rozwiązaniu.

@SeraMoon myślałem jeszcze chwilę o mojej wcześniejszej wypowiedzi i chciałem dodać dwa komentarze pomocniczne:

• Jeżeli podejmiecie się własnej implementacji drzewa, zdecydowanie zalecam, aby członkiem zespołu był przynajmniej jeden lekarz. Potrzebne będzie odpowiednie sformułowanie pytań a także wyjaśnienie konceptów (np. "duszność"), a do tego trzeba medyka.
• Kiedyś zajmowałem się programowaniem gier mobilnych i pomyślałem sobie, że aktualizacja grafu offline będzie wymagać aktualizacji całej aplikacji (jeśli się nie mylę). Czyli jeśli pojawi się nowy objaw wg WHO albo zmienią się kryteria, to mogą być osoby równocześnie korzystające z różnych wersji triage'u, co może rodzić różne problemy klasyfikacji.

To tyle. Pozdrawiam!

[SeraMoon]

@porz

Jeżeli pojawi się nowy objaw to z serwera zostanie pobrany JavaScript np. ocena-ryzyka.js, który wpłynie na działanie aplikacji. Cache-owanie będzie ustawione na 24 godziny, więc ryzyko użycia bardzo starego skryptu nie wystąpi. Jednak w rozweiązaniu będzie ta zaleta że nie będzie trzeba instalować żadnej aplikacji a odpowiedzi użytkownika nie będą trafiać na serwer.

Co do lekarza - pomyślę o konsultacji tego z lekarzem medycyny - jak pytania powinny być zadane. W sumie jest to też uwaga do obecnej aplikacji ProteGo.

Również pozdrawiam i dziękuję za udzieloną pomoc.

[potiuk]

@porz - > dzięki za komentarz.

Doskonale rozumiem że się odcinasz (jeśli mogę na Ty), kontrowersji w tym projekcie - zwłaszcza w kwesti kto i jak podekjmuje decyzje - jest sporo, I myślę że nigdy nikt nic do Intermedica nie miał, bo tak naprawdę, to decyzje spoczywają na @MateuszRomanow a w tle prawdopodobnie MC (nie wiemy bo nigdy nikt z Ministerstwa Cyfryzacji, mimo wielokrotnych prób nie okazał się odwagą, żeby reprezentować projekt.

Ja do tej pory byłem przekonany - nigdy to nie było powiedziane wprost - że Intermedica jest faktycznie jednym z poddostawców.

Totalnie mnie zdziwiło, a nawet powiem że zaskoczyło, że projekt komercyjny, zamówiony z wolnej stopy przez MC opiewający na okrągłą sumę (podobno 7-cyfrową), który ma potencjalnie kilkadziesiąt milionów uużytkowników korzysta z darmowego API (bez żadnej gwarancji, wsparcia etc.) . Dla mnie to jest spora niefrasobliwość a nawet rzekłbym niegospodarność. Ciekaw jestem co @MateuszRomanow i MC mają na ten temat do powiedzenia, bo to wygląda na sporą amatorszczyznę. Ja w żadnym projekcie komercyjnym, nie naraziłbym w ten sposób żadnego z moich klientów na takie ryzyko. Projekt szkolny, treningowy, Proof-of-Concept, owszem. Ale produkcyjny - nigdy

[KoderFPV]

@potiuk Nie widze związku pomiędzy darmowym API a amatorszczyzną.

100% bibliotek które używam w wielko budżetowych projektach jest darmowych (npmjs) Wiele serwisów które używam w wielko budżetowych projektach jest darmowa (cdn'y) Korzystamy z darmowej literatury w wielko budżetowych projektach i nikt nie kwestionuje jej profesjonalizmu.

Właściwie jeżeli chodzi o technologie, a API infermedica się do niej zalicza, to nic dziwnego że coś jest darmowe.

ps. https://github.com/apache/airflow Też jest darmowy, czy on też naraża klientów na ryzyko?

[potiuk]

Ja sam jestem jednym z najbardziej aktywnych commiterów a nawet członkiem PMC projektu Apache Airflow - projekt darmowy, open-source, rozwijany w dużej mierze przez społeczność. Ale to nie jest product dostępny jako "usługa", tylko instalowany i uruchamiany i zarządzany przez użytkownika..

I wiem o czym mówię bo nasz - darmowo dostępny projekt jest dostępny w kilku miejscach jako usługa - z płatnościami miesięcznymi, SLA (Service Level Agreement) i opłacanym wsparciem. Absiolutnie sobie nie wyobrażam korzystanie z darmowej usługi bez żadnej gwarancji że będzie działać w projekcie komercyjnym. W ogóle by mi to nigdy przez myśl nie przyszło. Takie rzeczy są w projektach komercyjnych zawsze dyskutowane na początku - SLA, gwaranje działania, koszty.

Software-As-A-Service (a taka właśnie jest usługa Intermedica) - to zupełnie inna bajka w każdej chiwli może "zniknąć". Jak ich dostawca internetu padnie, to pada również ProteGO, a wy nie macie żadnej alternatywy. Nawet nie macie do kogo zadzwonić po wsparcie. Szczerze - żenada.

To jest jakaś naprawdę bardzo zły pomysł. Rzekłbym ciekawy temat dla @tomekziel, który wystąpił o udostępnienie umowy do MC ( a wcześniej wywalczył dostęp do umowy Kwarantanny Domowej). Szczerze mówiąc, jak to słyszę, to resztki włosów mi stają dęba na głowie, bo to dla mnie jest całkowicie niezrozumiałe. Naprawdę, jeśli uważacie że wasza aplikacja ma pomagać ludziom i trzymać ich w zdrowiu, a jednocześnie robicie to za pomocą API które w każdej chwili może zniknąć, to to bardzo źle świadczy o stabilności tego projektu. Naprawdę jestem zawiedziony jak bardzo "amatorsko" (i powtórzę to jeszcze raz - w przeciwieństwie do "profesjonalnie") do tego podchodzicie.

[KoderFPV]

@potiuk Nadal nie zgadzam się z tym że używanie darmowego API takiej firmy infermedica świadczy o amatorskości.

To nie jest API do pokedexu pokemonów, użytkownika z redita. Infermedica to ogromny dostawca usług, z którego korzysta ogromna ilość podmiotów.

A to że pomaga w walce z COVID za pomocą darmowego API to tylko plus.

ps. Wręcz zdziwiłbym się jakby developerzy próbowali uzyskać bliźniacze rozwiązanie na początku projektu, zamiast skorzystać ze sprawdzonych rozwiązań i wykorzystać moce przerobowe, tam gdzie jest to najbardziej potrzebne, na danym etapie rozwoju.

Takie dysponowanie środkami przerobowymi, wyglądało by na bardzo nierozsądne w walce z COVID-19

[potiuk]

W świetle tego co pisał @porz w #161 -> to naprawdę jest tzw. jazda po bandzie licząc na to że bez wsparcia takie API bęðzie działać. Nawet nie wiecie (bo skąð?) czy to - darmowe - API jest w stanie znieść kilka milionów osób je używających. nie ma żadnych gwarancji, wsparcia, umowy.

Trochę wygląda jakbyście chcieli zwiększyć marżę kosztem ryzyka ludzi którzy będą to API używać.

W dalszym ciągu uważam że to bardzo amatorskie (niektórzy mogli by powiedzieć "cebulowe") podejście.

[KoderFPV]

@potiuk Biorąc pod uwagę, potencjalną architekturę takiego API, możliwości jego cachowania oraz wielkość firmy infermedica to podejrzewam, że może udźwignąć pół świata. :)

Infermedica, to dostawca także płatnych usług. Nie wykluczone, że podczas reaserchu, w pierwszej fazie projektu wybrano infermedica jako początkowo darmowego, a w późniejszej fazie komercyjnego partnera. Tego nie wiem, ale mogę się domyślać, że nie przeoczono tak istotnej sprawy.

Darmowe API infermedica, jak do tej pory nigdy nie zawiodło. Nie zawiodło aż do teraz, kiedy można zacząć rozmawiać o usprawnienie tej warstwy aplikacji. Nawet komercyjna współpraca, miałaby prawdobieństwo zakończyć się na poczet lokalnego rozwiązania, które jest proponowane tutaj #163

Więc dochodzę do wniosku, że do tej pory wybór Infermedica oraz ich darmowego API było w pełni profesjonalnym zachowaniem. Do tej pory nie zrobiono żadnego overengineeringu, który miałby zostać zastąpiony np. rozwiązaniem z #163, ani także dotychczasowe rozwiązanie nie zawiodło użytkowników.

So far so good :)

ps. Jestem dumny, że rozmawiamy o polskiej firmie :)

[potiuk]

@potiuk Biorąc pod uwagę, potencjalną architekturę takiego API, możliwości jego cachowania oraz wielkość firmy infermedica to podejrzewam, że może udźwignąć pół świata. :)

Totalne i niczym nie uzasadnione spekulacje. Chętnie zobaczyłbym rzetelne wyliczenia na którym sę opierasz a przynajmniej "Back-of-the-envelope" calculation. Z liczbami i założeniami. Na razie to jest tylko niczym nie uzasadniona wiara w coś o czym nie macie pojęcia. NIe macie żadnych gwarancji, nie wiecie jak to działa pod spodem bo z godnie z #161 -> nikt nigdy nie miał żadnej relacji z Twórcami tego API (celowo nie wymieniam bo @porz prosił w innym wątku żeby nie łączyć ich API z ProteGO). Cytat poniżej:

W związku z powyższym zwracam się z prośbą do uczestników dyskusji o nie linkowanie naszej firmy z projektem ProteGO w sposób, który sugerowałby, że jesteśmy jego współautorem lub podwykonawcą.

to dostawca także płatnych usług. Nie wykluczone, że podczas reaserchu, w pierwszej fazie projektu wybrano infermedica jako początkowo darmowego, a w późniejszej fazie komercyjnego partnera. Tego nie wiem, ale mogę się domyślać, że nie przeoczono tak istotnej sprawy.

Z tego co mówi @porz w #161 żaden sposób nie ma relacji z ProteGO, a nawet z jego tonu wypowiedzi wnioskuję, że nie bardzo są tym zainteresowani. To komercyjne API które mają nie dotyczy COVID-19 tylko jest przydatne w medycynie rodzinnej i pozwala diagnozować 660 jednostek chorobowych. To jest jednak inna usługa. I z tej wypowiedzi wynika że nikt z nimi o tym do tej pory nie rozmawiał.

Darmowe API infermedica, jak do tej pory nigdy nie zawiodło.

COVID-19 też nigdy jeszcze nie było, a nagle się trafił. Ten argument akurat nie mówi totalnie niczego, choćby dlatego że ProteGO jest używane pewnie przez promil ludzi. Ściśle rzecz biorąc około 0.5 promila (jeśli wierzyć ~ 10.000+ instalacjom w PlayStore). W związku z tym nikt nie wie jak to API się będzie zachowywać pod obciążeniem. Rozumiem że dalej istotą jest osiągnięcie powszechności instalcji. Jeśli chcecie osiągnąć 50% to macie 15.000.000 osób czyli jakieś 1500x większy ruch. Nie da się zupełnie nic wynioskowąć o stabilności tego darmowego API na tej podstawie. Jeśli ktoś chciałby na tej podstawie (bez SLA i zapewnień od dostawcy wnioskować że 1500 x większy ruch jest OK, to na pewno profesjonalizmem bym tego nie nazwał. Hazardem raczej.

Nie zawiodło aż do teraz, kiedy można zacząć rozmawiać o usprawnienie tej warstwy aplikacji. Nawet komercyjna współpraca, miałaby prawdobieństwo zakończyć się na poczet lokalnego rozwiązania, które jest proponowane tutaj #163

No ja mówię o przyszłości właśnie. O tym żeby to zaplanować i podjąć decyzję. Sporo osób na to zwraca uwagę, @MateuszRomanow całkiem niedawno - przy okazji #147 (poprawione - chodziło o #134) pisał jak fantastycznym rozwiązaniem jest proxy które ma dawać anonimowość i w ogóle to był bardzo fajkny pomysł od początku, a tymczasem może się okazać, że to niepotrzebne, bo będzie (z reszta sugerowane przez @porz w #161 rozwiązanie lokalne. Czy to przemyślana strategia? nie wiem.

Więc dochodzę do wniosku, że do tej pory wybór Infermedica oraz ich darmowego API było w pełni profesjonalnym zachowaniem.

Zobaczymy, co będzie dalej. Ocena profesjonalizmu zależ od celu który aplikacja ma osiągnąć i tego czy jesteście jego świadomi.

Ja mam niestety obawę że MC zobaczyło że nic tu nie ugra i straciło zainteresowanie. Mam też nadzieję że nie ubije całego projektu nieumiejętność/niemożność zorganizowania całej logistyki do testów które są według mnie warunkiem koniecznym. żeby takie rozwiązanie wprowadzać. Jeśli dalej celem jest szybkie wdrożenie na dużą skalę - to brak dobrego rozwiązania, rozmów z partnerem który zapewnia usługę (jak wnioskuję z jego wypowiedzi), brak zapewnienia stabilności i bvrak podejmowania świadomych decyzji mając choć trochę rozeznania w usłudze, której się używa - świadczy według mnie o braku profesjonalizmu i pozwolę sobie tak to oceniać.

Jeśli celem jest po prostu zrobienie aplikacji bez celu "powszechność" - to być może jest to faktycznie dobre że nie przeinwestowujecie i chcecie po prostu jak najmniej wydać, żeby jak najwięcej zostało w marży.

Do tej pory nie zrobiono żadnego overengineeringu, który miałby zostać zastąpiony np. rozwiązaniem z #163, ani także dotychczasowe rozwiązanie nie zawiodło użytkowników.

So far so good :)

Mi się przypomina po takim zdaniu klasyk "My z synowcem na czele .... i jakoś to będzie"

ps. Jestem dumny, że rozmawiamy o polskiej firmie :)

A co ma jedno z drugim wspólnego? Wnioskując z wypowiedzi @porz (może się mylę) oni raczej w drugą stronę dumni nie są (być może dlatego że nie wiedzą kim jesteście i co aplikacja ma robić). Dla mnie ważne - i zawsze tak było - nie to kim kto jest ale co sobą reprezzentuje. Zupełnie nie interesuje mnie narodowość, kolor skóry, płeć. Myślę że w relacji biznesowej ważne jest przede wszystkim właśnie profesjonalizm. W wielu przypadkach umiejętność zarządzania ryzykiem i świadome podejmowanie decyzji. Nie mam podstaw żeby tu było inaczej, jeśli chodzi o świadomość - być może ta decyzja - jeśli była świadomie powzięta - była podjęta z analizą i rozumieniem ryzyk. Może właśnie w końcu przydało by się odpowiedzieć na apel m.in. Panoptykonu o opublikowanie analiz ryzyka, które - niewątpliwie - w takim projekcie powinny być przeprowadzone.

[miklobit]

Software-As-A-Service (a taka właśnie jest usługa Intermedica) - to zupełnie inna bajka w każdej chiwli może "zniknąć". Jak ich dostawca internetu padnie, to pada również ProteGO, a wy nie macie żadnej alternatywy. Nawet nie macie do kogo zadzwonić po wsparcie. Szczerze - żenada.

Wydaje się że kwestia relacji Infermedica ze stroną rządową, schemat przepływu danych i zasady udostępniania rządowi API powinna zostać oficjalnie wyjaśniona (zgodnie z #155 które - przypominam - nie doczekało się na razie odpowiedzi...) ponieważ to samo API, z tym samym zestawem pytań co w Protego jest wykorzystywane przez rząd na stronie https://pacjent.gov.pl/koronawirus/sprawdz-objawy "Sprawdź, czy masz objawy COVID-19" . Tyle, że nie przez API url ale w formie strony Infermedica wstawionej na rządową stronę jako iframe ( url: https://covid19-moh.infermedica.com/pl ). Dopiero zalinkowany tam tekst polityki prywatnosci infromuje, że obywatel (który ufa, że jest na stronie rządowej !) faktycznie ogląda stronę serwowaną przez infermedica a dane które wprowadza faktycznie lądują gdzieś na serwerze zewnętrznej prywatnej firmy. @porz - czy ten serwis też jest rządowi udostępniony "as-is" za darmo (jak dla Protego-Safe ) i czy każdy też sobie może wstawić tę waszą stronę jako iframe w swoim serwisie ? Z tego co widzę, to polityka prywatności w ogóle nie porusza takiej ewentualności, że wasz serwis bęðzie opakowany w jakąś inna domenę bo ta polityka w ogóle to twierdzi że usługa jest świadoczna pod url'em https://www.symptomate.com - co już kompletnie może zdezorientować każdego kto to czyta

Z tego co mówi @porz w #161 żaden sposób nie ma relacji z ProteGO, a nawet z jego tonu wypowiedzi wnioskuję, że nie bardzo są tym zainteresowani. To komercyjne API które mają nie dotyczy COVID-19 tylko jest przydatne w medycynie rodzinnej i pozwala diagnozować 660 jednostek chorobowych. To jest jednak inna usługa. I z tej wypowiedzi wynika że nikt z nimi o tym do tej pory nie rozmawiał.

Jeżeli nie ma formalnych relacji między Infermedica a ProteGO (-> czyli efektywnie MC) to czy Infermedica wie, że jest przywołana w polityce prywatnosci Protego, ( gdzie jest link do polityki prywatnosci Infermedica) i czy na takie zapisy się zgodziła @porz ? Dla użytkownika końcowego takie zapisy świadczą jednoznacznie, że to nie jest relacja typu "wołamy darmowe api ktore ktoś wystawił, my znaleźliśmy w necie ale nie odpowiadamy za to co ono zwraca i czy w ogóle działa bo wystawca daje nam go as-is jako czarną skrzynkę bez żadnych gwarancji"

[MateuszRomanow]

@MateuszRomanow całkiem niedawno - przy okazji #147 pisał jak fantastycznym rozwiązaniem jest proxy

1. @potiuk Proszę o rzetelność w cytowaniu, i nie przedstawianie prywatnych interpretacji jako faktów. W #147 proxy pojawia się w jednym zdaniu "API Proxy do Infermedica (pliki konfiguracyjne Nginx) / dostępny tutaj / licencja AGPL" nie ma tam tego co przedstawiasz. Trzymajmy się faktów.

2. Rozwiązanie od @porz na każdym etapie było i jest najbardziej dojrzałym rozwiązaniem, oficjalnie wdrożonym na pacjent.gov.pl i skutecznie pomagającym tysiącom ludzi codziennie (w peaku z API korzystało kilkadziesiąt tysięcy osób równolegle).

3. Temat przejścia z online do offline jest otwarty.

[porz]

Myślę, że kwestia relacji pomiędzy Infermedica a projektem ProteGO została wyjaśniona w #161 tj. nie mamy podpisanych umów, nie zabiegamy o to, nie jesteśmy podwykonawcą. ProteGO korzysta z naszego darmowego API, podobnie jak kilkuset innych użytkowników COVID-19 API.

W kwestiach niezwiązanych bezpośrednio z projektem ProteGO zapraszam do kontaktu osobiście: piotr.orzechowski@infermedica.com. W miarę możliwości temat przekieruję do odpowiednich osób z działu prawnego, produktowego lub technicznego. Niemniej jednak na dwa pierwsze pytania odpowiem w imię transparencji, choć nie dotyczą ProteGO, a po prostu działalności naszej firmy i rozumiem, że macie pytania.

@porz - czy ten serwis też jest rządowi udostępniony "as-is" za darmo (jak dla Protego-Safe ) i czy każdy też sobie może wstawić tę waszą stronę jako iframe w swoim serwisie ?

Zgadza się. Portal pacjent.gov.pl korzysta z naszej usługi w postaci iFrame nieodpłatnie. Dla kluczowych partnerów - jakim oczywiście jest MZ - udostępniamy darmowe wsparcie oraz pomagamy w customizacji rozwiązania.

Kod do osadzenia iFrame'a można pobrać tutaj po wcześniejszym kontakcie z naszym zespołem: https://infermedica.com/covid19

Z tego co widzę, to polityka prywatności w ogóle nie porusza takiej ewentualności, że wasz serwis bęðzie opakowany w jakąś inna domenę bo ta polityka w ogóle to twierdzi że usługa jest świadoczna pod url'em https://www.symptomate.com - co już kompletnie może zdezorientować każdego kto to czyta

Przygotowanie odpowiedniej polityki prywatności i regulaminu usługi spoczywa na właścicielu strony, która udostępnia iFrame. Takowej niestety w tym przypadku jeszcze nie otrzymaliśmy do podmienienia, więc zgadzam się, że wykorzystanie PP z naszej strony symptomate.com jest nieco mylące i pracujemy nad tym to poprawić. Again, nie ma to związku z ProteGO.

Jeżeli nie ma formalnych relacji między Infermedica a ProteGO (-> czyli efektywnie MC) to czy Infermedica wie, że jest przywołana w polityce prywatnosci Protego, ( gdzie jest link do polityki prywatnosci Infermedica) i czy na takie zapisy się zgodziła @porz ?

Dziękuję za zwrócenie uwagi. Nie wyrażaliśmy na to zgody, ja o tym nie wiedziałem, ale temat pozostawiam do dyskusji prawnikom. Z tego co rozumiem w politykach prywatności często przywołuje się nazwy zewnętrznych dostawców (np. Google Analytics), więc to niekoniecznie zła praktyka!

[kierepka]

Brawo - cieszę się, że są takie firmy jak Infermedica i tak odpowiadają.

[potiuk]

Propsy za szybkie i bardzo rzeczowe odpowiedzi @porz!

[potiuk]

@MateuszRomanow całkiem niedawno - przy okazji #147 pisał jak fantastycznym rozwiązaniem jest proxy

1. @potiuk Proszę o rzetelność w cytowaniu, i nie przedstawianie prywatnych interpretacji jako faktów. W #147 proxy pojawia się w jednym zdaniu "API Proxy do Infermedica (pliki konfiguracyjne Nginx) / dostępny tutaj / licencja AGPL" nie ma tam tego co przedstawiasz. Trzymajmy się faktów.

Uwielbiam trzymać się faktów. I mam nadzieję że w dalszej części tej dyskusji też będziesz to robił - bo na przykład w tym poście który napisałeś, nie ma ani jednego faktu. Są niczym nie poparte stwerdzenia w dodatku sformułowane tak, że nie mówią one kompletnie nic. Coi do mojego numerka - faktycznie - pomyliłem numerki. Chodziło o #134 - już poprawiłem. Tak gwoli ścisłości chodziło o to Twoje zdanie ze #134:

c) serwer, który jedynie propaguje dalej bez zapisu zuploadowaną historię kontaktu; (co ciekawe, taki PoC stworzyliśmy razem z Sigmą jeszcze na etapie SafeSafe 4-5 tygodni temu. Zastąpiliśmy go później znacznie dojrzalszym rozwiązaniem OpenTrace).

Być może faktycznie nadinterpretowałem, że również chodzi to o NGINX-a do Intermedica (o NGINX wielokrotnie pisałeś w różnych miejscach, ale zdaje sie specyfikacji brak). Niestety musiałem to zrobić bo nie odpowiedziałeś na moje, precyzujące pytanie:

https://github.com/ProteGO-Safe/specs/issues/134#issuecomment-622975017

Co do c) nie bardzo rozumiem o co chodzi z tym serwerem. Dobrze by było wiedziec o co chodzi, bo to o czym, piszesz to trochę dziwne w kontekście a) b) tego że decyzje mają być podejmowane lokalnie - historia kontaktów na serwerze jest do tego kompletnie niepotrzebna. Proponuję może otwórz oddzielne issue gdzie to opiszesz, myślę że chętnie o tym wszyscy podyskutują.

Może najwyższy czas żeby ta opisana architektura w końcu się pojawiła, bo czasem naprawdę nie wiemy o czym rozmawiamy. To już grubo ponad tydzień kiedy było powiedziane że tak będzie. Czy możesz proszę wyjaśnić o co chodzi w punkcie c) i czy to ma coś wspólnego również z proxy do Intermedica?

2. Rozwiązanie od @porz na każdym etapie było i jest najbardziej dojrzałym rozwiązaniem, oficjalnie wdrożonym na pacjent.gov.pl i skutecznie pomagającym tysiącom ludzi codziennie (w peaku z API korzystało kilkadziesiąt tysięcy osób równolegle).

No i tu @MateuszRomanow prośba o fakty właśnie (bo ich tu jest dokładnie zero). Po pierwsze skąd te dane? Czy mógłbyś podać źródło? Po drugie - co to znaczy "kilkadziesiąt tysięcy osób równolegle" ? W tej samej sekundzie, minucie, godzinie, 24h, czy jakichś innych jednostkach ? Ile było "żądań" równolegle? Jaki miały rozmiar? Jakie było natężenie w "szczycie". W tej chwili to jest nic nikomu nie mówiący slogan, bez poparcia w danych i bez jakichkolwiek przemyśleń.

Podpowiem metodologię (tak przynajmniej ja, i najlepsi inżynierowie jakich znam robią zawsze na początku projektu). Jest spora szansa że może po prostu nie zorientowaliście się z jakim problemem macie do czynienia, bo tego nie zrobiliście i jedziecie na tak zwane "yolo". Ja sobie nie wyobrażam zaczęcia projektu bez zrobienia podstawowych szacunków.

Jedną z pierwszych rzeczy które zrobiłem jak myśleliśmy o pierwowzorze Protego były "obliczenia na odwrocie koperty" (ang. "Back of the envelope calculation"). Czyli szacunkowa ocena ruchu który jesteśmy w stanie wygenerować. To były trochę inne założenia niż teraz, ale wyniki tego możecie obejrzeć tu:

Bardzo w skrócie - jeśli przyjąłem założenie że aplikacja sama będzie robić 1 (!) sprawdzenie na dzień (i równo - probabilistycznie) rozłożymy ruch na dzień i noc, to przy 30M osób wychodzi nam 350(!) żądań na sekundę. Cały czas, bez przerwy, dzień i noc. Całkowita transmisja danych - 3TB /dzień. Dużo. Bardzo dużo nawet.

W przypadku API intermedica (i każdego innego), żeb zrobić takie obliczenia, trzeba by przyjąć jakieś szacunkowe założenia:

• ile razy na dzień 1 osoba sprawdza stan zdrowia
• czy będą "peak times" (podpowiem - będą po południu po powrocie/skończeniu pracy). Ile osób skumuluje się podczas załóżmy "peak hour" (to najczęściej przyjmowany okres czasu do takich obliczeń).
• ile żądań do backendu jest generowane przy jednym sprawdzeniu
• jak długo trwa taka sesja (to mniej potrzebne ale przydatne żeby określić jak długo będzie trwał "peak-time"
• ile danych jest wysyłanych/pobieranych z serwera średnio podczas żądania
• przydały by się jeszcze rozkłady/mediany ale do podstawowych szacunków powyższe powinno wystarczyć

Nie wiem jakie macie szacunki. Ja nie mam danych, ale mogę zgadywać . Nie wiem jak to działa, jak działa cache pod spodem etc. Ale pobawię się w zgadywanie:

• Zakładam sprawdzenie raz na 2 dni
• API jest w JS, zadaje pewnie ~ 10 pytań i to jet ciągła wymiana tam i z powrotem
• Pewnie to jakieś 30 (zgaduję kompletnie?) żądań na sesję
• pewnie jakiś 1 KB średnio na żądanie (uwzględniając narzuty/http etc.).
• Zakładam że 30% ludzi będzie sprawdzać w peak hour
• Zakładam że 50% ludzi będzie miało zainstalowaną aplikację.

Przy tych założeniach jest ~40.000 żądań na sekundę (!!!!!!). Nie 500, nie 1000. To jest 40.000 żądań na sekundę (!!!!). Do tego jst 140 GB do transferu w trakcie "Peak hour"

Nie wiem czy pana @porz to przeraża, ale gdybym ja miał mieć darmowe API i obsługiwać 40.000 żądań na sekundę i ćwierc terabajta do transmisji w "peak hour" to bym się mocno zastanowił, czy tego nie wyłączyć.

Poza tym jak już wchodzimy w dziesiątki tysięcy żądań na sekundę, to wasze NGINX proxy zdechnie natychmiast. Chyba że będziecie mieli z prawdziwego zdarzenia load balancing etc.

Nie wiem czy to wszystko policzyliście wcześniej - ale powinniście.

Aktualizacja: (poprawiłem dane bo nie podzieliłem przez w w założeniu że sprawdzanie robimy raz na 2 dni)

Aktualizacja: Najważniejsze pytanie i to pewnie do @porz - jak dobrze te wywołania API można scacheować i jak bardzo można wykorzystać rozwiązania typu CDN (Content Delivery Network). W moich założeniach, założyłem że będzie to 30 nie-cacheowalnych żądań na sesję (czyli takich które faktycznie docierają do serwerów Intermedica).

[KoderFPV]

@potiuk

Nie wiem czy to wszystko policzyliście wcześniej - ale powinniście

Te wszystkie obliczenia, to bardzo bardzo podstawowe wyliczenia.

Skoro pan to zrobił w tak krótkim czasie, to nie możliwe, że developerzy nie pomyśleli o tym w trakcie 3 miesięcy developmentu. To są rzeczy, nad którymi się zastanawia jeszcze przed pierwszą linijką w kodzie. Wspomina pan podstawy, podstaw.

Może najwyższy czas żeby ta opisana architektura w końcu się pojawiła, bo czasem naprawdę nie wiemy o czym rozmawiamy

Dzisiaj rozpoczeły się prace, w związku z #155

I co do wątpliwości infrastruktury prosiłbym o osobne wątki wmiarę możliwości. Temat dotyczy mniej technicznych rzeczy.

[tomekziel]

To są rzeczy, nad którymi się zastanawia jeszcze przed pierwszą linijką w kodzie. Wspomina pan podstawy, podstaw.

Mówimy o tym samym profesjonalnym zespole, który przepuścił "Missing TempID" w wersji sklepowej 3.0.1?

Jeśli ktoś nie zna tej rozkosznej wpadki, to wspomniałem o niej tutaj: https://informatykzakladowy.pl/co-tak-naprawde-aplikacja-protego-safe-nadaje-przez-bluetooth/

[pkleczko]

@tomekziel dzięki za uszczypliwość :) - tak błąd się zdarzył a nie powinien był. Był wynikiem niedopatrzenia, które wynikało z chęci jak najszybszego wypuszczenia aplikacji. Poprawiliśmy proces żeby do tego ponownie nie dopuścić, ale jak słusznie zauważyłeś "pomyłki się zdarzają", nawet najlepszym. Jeśli nigdy takowej nie miałeś, również na produkcji to zazdroszczę i gratuluję. Artykuł fajny i merytoryczny, czytałem go jak wiele osób już wczoraj czy przedwczoraj, nie musisz go moim zdaniem promować w tematach z nim niezwiązanych.

[potiuk]

@potiuk

Te wszystkie obliczenia, to bardzo bardzo podstawowe wyliczenia.

Na tym właśnie polega "back-of-the-envelope" calculation. Żeby w krótkim czasie oszacować o jakiej skali mówimy. I to jest dziwne ale zdecydowana większość programistów w ogóe tego nie robi tylko ufa swojej intuicji. I na przykład rzuca takie - zupełnie nic nie mówiące stwierdzenia jak @MateuszRomanow wczoraj "(w peaku z API korzystało kilkadziesiąt tysięcy osób równolegle).". Każdy rozsądny inżynier widzi że to idzie na "yolo".

Skoro pan to zrobił w tak krótkim czasie, to nie możliwe, że developerzy nie pomyśleli o tym w trakcie 3 miesięcy developmentu.

Zdziwiłby się pan. Widziałem już bardzo wiele sytuacji. Sam z resztą kiedyś taką miałem, Jeśli mówimy o popenianiu błędów - to mam taki jeden. Musiałem przez niego wrócić z połowy drogi do dmu na święta wielkanocne do domu. Właśnie zaczął się Ramadan i nagle gra, którą pisaliśmy na rynek Arabski "chwyciła" - a my nie zrobiliśmy takich obliczeń "back of the envelope". Potem 48 godzin pracy bez przerwy i udało się. Na szczęście mieliśmy "zwornik" bezpieczeństwa - gra działała przez jakiś czas nawet bez dostępu do serwera. To był dla mnie ostatni raz bez "back-of-the-envelope".

To są rzeczy, nad którymi się zastanawia jeszcze przed pierwszą linijką w kodzie. Wspomina pan podstawy, podstaw.

Nie pytam czy "się zastanawia", tylko czy wy się zastaowiliście. Jeśli to podstawy podstaw, to bardzo poproszę o te wyliczenia. Ja swoje pokazałem, Czekam na wasze wyliczenia i wnioski. Z moich założeń (Ale tak jak mówię - zgaduję) wynika że macie problem. Ciekawe co wynika z waszych.

Może najwyższy czas żeby ta opisana architektura w końcu się pojawiła, bo czasem naprawdę nie wiemy o czym rozmawiamy

Dzisiaj rozpoczeły się prace, w związku z #155

Cieszę się.

I co do wątpliwości infrastruktury prosiłbym o osobne wątki wmiarę możliwości. Temat dotyczy mniej technicznych rzeczy.

Proszę bardzo. Zaraz otwieram.

[kwiszowaty]

Koleżanki i Koledzy,

Przepraszam, że nie na temat, ale muszę to napisać.

Czytam ten wątek i aż łapię się za głowę z niedowierzania w którą stronę to poszło. O ile idea dla której powstał post jest jasna i całkowicie się z nią zgadzam, to forma jaką to przybrało budzi we mnie niechęć. Nie ma to nic wspólnego z profesjonalizmem.

Ostatnią wymianę komentarzy mogę śmiało porównać do kłótni dzieci z piaskownicy o to czyja łopatka jest lepsza, a które zupełnie zapomniały, że miały razem zbudować zamek z piasku. Nikt nie słucha argumentów bo broni swoich racji.

@potiuk, o ile podziwiam Twoją wytrwałość, zaangażowanie i zapewne rozległą wiedzę, to wydaje mi, że trochę przeginasz. Tak jak pisałeś w innym wątku, to pewnie przez brak snu i zmęczenie/irytację tą całą sytuacją (nawet nie zauważyłeś sarkazmu @Tarvald'a pod Twoim adresem). Czytając Twoje ostatnie komentarze, pomimo tego, że wiem, że chcesz dobrze dla projektu, to nachodzą mnie myśli czy wszyscy mają wspólny cel? Czy chcemy pomóc by projekt był lepszy czy go storpedować?

Proszę dajmy trochę na luz, ostudźmy emocje, nie bierzmy tego personalnie, bądźmy profesjonalistami. Nie oznacza to, ze mamy odpuszczać - mamy dalej cisnąć, ale zachowując pełny profesjonalizm. Zamieńmy wytykanie błędów na konstruktywną krytykę, insynuacje na ustalanie faktów. Można to zrobić bez złośliwości i uszczypliwości. Bez udowadniania winy czy tego, że moja racja jest "mojsza".

Weźmy proszę pod uwagę, że w tym, zresztą jak w każdym innym projekcie, są różni ludzie. Z większym i mniejszym doświadczeniem. Nie każdy wie wszystko. Dlatego też mamy możliwość by projekt wspomóc. Ale konstruktywnie, przez rozmowę. Jak zaczniemy od udowadniania, że druga strona to się nie zna wcale i lepszy projekt by napisał student, to daleko nie zajedziemy. Naturalnie nastąpi blokada i nikt już nie usłyszy Twoich argumentów, choćby nie wiem jak racjonalne były.

Jak reagujecie na komentarze pod swoim projektem, które znajdują błąd i od razu zarzucają Wam totalny brak profesjonalizmu? A co gdy zgłosi takich błędów kilka? Czy nie możecie się doczekać by przeczytać każdy z nich, czy jak tylko przyjdzie powiadomienie, to czujecie irytację?

A tu potrzeba dialogu. A nawet partnerstwa. Żeby druga strona chciała słuchać.

Może jestem idealistą, ale ciągle wierzę, że dialog jest możliwy. Szczególnie z osobami technicznymi na tym kanale. Pamiętajmy, że oni też "szyją z tego co mają" i poruszają się w ograniczonej rzeczywistości. Nie jest to projekt w którym możesz wszystko. Wierzę, że mając poparcie zespołu technicznego będziemy mieli ogromny wpływ na docelowy kształt rozwiązania (i nawet MC nie stanie na przeszkodzie).

I na koniec prośba: pisząc komentarz zastanówmy się, czy w takiej formie chcielibyśmy go widzieć pod naszym projektem.

Dzięki, Karol

PS1 @porz Pełen profesjonalizm, gratuluję.

PS2 @Tarvald @MateuszRomanow w tym wątku @potiuk poruszył bardzo ważną kwestię wydajności systemu. W pełni go rozumiem i popieram. Nie chcę by zginęły w gąszczu przepychanek słownych. Musicie na to zwrócić uwagę i jeżeli takowe wyliczenia były robione, to prośba o udostępnienie. Jeżeli nie, to trzeba to nadrobić jak najszybciej.

PS3 Nie mam nic wspólnego z ProteGO, piszę ten komentarz jedynie ze względu na dobro projektu.

[potiuk]

Dzięki @kwiszowaty . W pełni się zgadzam że fajnie by było nawiązać dialog. Próbuję od jakiegoś czasu. Nie wiem czy nie zauważyłeś ale ja cały czas włąśnie konstruktywnie propnuję przyjrzenie się i działania, które sam bym robił w aplikacji (ale przypomnę że nie jest to projekt open-source tylko komercyjny projekt zamówiony u Twórców, więc trudno spodziewać się że "konstruktywność" wyjdzie poza pokazanie potencjalnych problemów, zwrócenie na nie uwagi Twórców i (to dla mnie najważniejsze) społeczny nadzór nad tym, żeby prywatność ludzi nie była naruszona. Wydaje mi się że staram się pokazać że zrobienie obliczeń pomogły by w określeniu, czy problem jest, czy nie. Starałem się wcześniej uzyskać na ten temat informacje, ale na razie nie dostałem.

Nic nie jest emocjonalne, po prostu staram się pokazać fakty i lczby i co z tego wynika. Chętnie porozmawiam (w innym wątku najlepiej), w którym miejscu przegiąłem ? Pokazałem tylko to wyliczenie które zrobiłem 2 miesiące temu i zrobiłem podobne, nie mając (niestety) pełnych danych.

Otworzyłem https://github.com/ProteGO-Safe/specs/issues/166 tak jak prosił @Tarvald .

[kwiszowaty]

@potiuk żeby było jasne: uważam, że robisz tu naprawdę dobrą robotę. Gdy dochodzi do części technicznej to nie da się nic zarzucić. Chciałem tylko zwrócić uwagę, że można lepiej i przyjemniej dla obu stron, a co najważniejsze może to być korzystne dla projektu.

Chętnie o tym porozmawiam (masz mój mail w profilu, mogę też dać telefon) ale jak sam przeczytasz na spokojnie swoje komentarze z tego ticketu, to zobaczysz, że kilka rzeczy można było napisać lepiej a kilka w ogóle pominąć.

[SeraMoon]

Powiem od siebie tyle - profesjonalnym podejściem będzie zaimplementowanie oceny ryzyka po swojej stronie i pilnowanie by była aktualna + stworzenie systemu aktualizacji aplikacji, np przez pobieranie szablonu oceny ryzyka z serwera aplikacji.

Wszelkie darmowe podejścia "ASIS" bez wsparcia (czytaj TOS) to jest najgorsza amatorszczyzna jakiej można się podjąć w tak ważnym projekcie. W TOS zapewne nie znajdzie się gwarancja dostępności usługi przez 100% czasu. Gdybym prowadziła darmowy serwis a ktoś by mi siał 40 tys. żądań na sekundę to dałabym mu bana na jego żądania i twierdziłabym że nie wiem o co chodzi lub zwracała mu komunikat 403 Access Denied z informacją, że dokonał DDoSa. Nie używa się darmowego API do takich celów. Zwyczajnie jest to nieprofesjonalne.

Polecam użyć JS5 lub C++ do stworzenia własnej implementacji, która się nie przeciąży, bo na jednym komputerze (smartfonie) będzie wykonywany jeden skrypt (ocena ryzyka) jednocześnie. Wtedy można powiedzieć o profesjonalizmie tego rozwiązania.

W sytuacji otwartego kodu (w postaci diagramów) które dostaliśmy od firmy, CDC oraz WHO dalsza próba promowania tutaj zewnętrznego API oraz serwera Proxy, gdzie dostęp ma Ministerstwo do IP oraz udzielonych odpowiedzi to jest nic innego jak promowanie inwigilacji. Inaczej po prostu tego nazwać się nie da.

Zapraszam więc do #163 Implementacji oceny ryzyka po stronie klienckiej / aplikacji.

[miklobit]

Powiem od siebie tyle - profesjonalnym podejściem będzie zaimplementowanie oceny ryzyka po swojej stronie i pilnowanie by była aktualna + stworzenie systemu aktualizacji aplikacji, np przez pobieranie szablonu oceny ryzyka z serwera aplikacji.

Najpierw należałoby zacząć od pytania ( @porz ? ) jak często (i czy w ogóle) się zmieniał graf decyzyjny lub jego parametry dt COVID19 w API od czasu kiedy aplikacja ProteGO jest wystawiona w sklepie. Bo jeżeli to jest np rzadziej niż raz na tydzień to regularne odpytywanie serwera o ew nową wersję jest niepotrzebnym generowaniem całkiem sporego ruchu, który chociaż mniejszy niż w przypadku triażu przez API też może być momentami znaczący. Czyli wtedy zdecydowanie lepsza aktualizacja grafu w formie nowej wersji aplikacji (co od razu: 1. Poinformuje usera, że coś się zmieniło, 2. wymusi pokazanie się zmian tu w repozytorium. A jak to będzie gdzieś zaszyte do pobierania dynamicznie to nie ma pewności, że ktoś będzie dbał o aktualizację repo ). A drugi argument za statycznym lokalnym kodem do triażu jest taki, że regularne odpytywanie serwera o nowy graf przez miliony userów (np raz dziennie) generuje kolejny prezent dla rządu w postaci danych gdzie, kto i jak czesto używa apki. A tego chyba nie chcemy ? Gdyby jednak graf miał być ładowany dynamicznie to powinien być wersjonowany na GH niezależnie od kodu aplikacji a informacja o tej wersji powinna być widoczna wewnątrz aplikacji.

[SeraMoon]

@miklobit tyle, że w aplikacji web można prace już zacząć, bo i tak musi to być pobrane.

Wiedza rządu, że raz na tydzień aplikacja pobiera jakiś JS już przynajmniej nie jest daną wrażliwą tak jak obecnie jest daną wrażliwą wysyłanie tam za każdym razem odpowiedzi.

Co do częstości zmiany tego grafu decyzyjnego, zwróć uwagę, że jego numer był V4, a poprzedni miał wersję V3. Czyli w trakcie życia aplikacji zmienił się 3 razy?

[porz]

Co do częstości zmiany tego grafu decyzyjnego, zwróć uwagę, że jego numer był V4, a poprzedni miał wersję V3. Czyli w trakcie życia aplikacji zmienił się 3 razy?

Zgadza się. Do tej pory były trzy aktualizacje, obecna wersja to V4. Zmiany w grafie uzależnione są od zmian wytycznych WHO, ale one zmieniają się raczej rzadko, jeśli chodzi o kluczowe kryteria kliniczne. Mając na uwadze, że w wielu krajach pandemia (wydaje się) przyhamowała, WHO pewnie nie będzie istotnie zwiększać częstotliwości zmian wytycznych w kwestii klasyfikacji pacjentów.

Innym czynnikiem są aktualizacje tzw. transmission reports. Stąd bierzemy informacje, czy dany kraj uznawany jest za miejsce "wysokiego ryzyka" czy nie. Podobnie jak w przypadku kryteriów klasyfikacji, tempo zmian tutaj również maleje. Przykład: https://www.who.int/docs/default-source/coronaviruse/situation-reports/20200316-sitrep-56-covid-19.pdf?sfvrsn=9fda7db2_6

W skrócie - musi istnieć mechanizm aktualizacji grafu, ale można bezpiecznie przyjąć, że będzie się to odbywać raczej raz na parę tygodni.

[SeraMoon]

@porz

Dzięki za potwierdzenie moich wcześniejszych przypuszczeń. Też logicznym jest, że aby powstał nowy graf musi nastąpić obserwacja lekarska, analiza danych, a to zajmie duuuużo więcej czasu niż zapisanie w JS5 czy innym języku programowania tego grafu.

BTW. Pójdę nawet dalej z tym grafem - jeżeli tylko okaże się to możliwe (nie przeanalizowałam całości) i napiszę to hakami w CSS - to jest tak prosty graf decyzyjny, że bez obsługi JS i jednocześnie bez wysyłania odpowiedzi użytkownika uda się to wykonać. W JS można do local storage zapisać użytkownikowi jakie miał kiedy objawy, aby mógł je potem z urządzenia przywrócić na wizycie szpitalnej.

[KoderFPV]

@MateuszRomanow potwierdził prace nad modułem offline #166

[SeraMoon]

@Tarvald chwali się. Będzie skończone, wątek można będzie zamknąć, zaś źródła gdzie są grafy decyzyjne - należy zachować w specs, aby nie zaginęło.

[KoderFPV]

@SeraMoon Dla modułu offline, zostanie stworzona odpowiednia dokumentacja.