Možnost hlásit symptomy covidu a podezření nákazy do databáze i bez PCR testu a kódu

[brozkeff]

Čekací doby na PCR testy jak pro indikované tak samoplátce už jsou týden a víc. I lékaři říkají, že kdo má mírné příznaky, např jen ztrátu čichu a únavu nemá zbytečně vytěžovat systém testů, má jen zůstat sám doma v karanténě a jít na kontrolní test až po odeznění příznaků. Jenomže takové doporučení úplně znemožňuje, aby takto patrně-pozitivní, ale neotestovaný, kdykoli do aplikace zadal kód z PCR testu, a celý systém eRoušky je nefunkční, protože nikdy nikomu nepřijde od takových lidí notifikace, že byli v kontaktu.

IMHO pokud připustíme, že není reálné všechny okamžitě PCR testovat a zpoždění na vyšetření je týden i víc, a řada lidí se na to vykašle úplně, případně lékaři je ani na vyšetření nepošlou a jen řeknou ať jsou doma, je nutné přidat krom stavu ID "nenahlášený/negativní" (není v databázi pozitivních), a stavu "plně pozitivní" i třetí stav "podezření na covid/zatím netestovaný" a mělo by tak jít se sám nahlásit do databáze jen jako "podezřelý" a pak dodatečně případně poslat PCR test jako pozitivní, a tím zpětně podezřelá ID "přebarvit" na infikovaný stav, a nebo nahlásit i NEGATIVNÍ výsledek PCR testu a dříve nahlášené podezření vzít zpět.

Umožňuje toto vůbec Exposure Notification API? Pokud ne, není asi naděje aby Google a Apple kvůli problémům v Česku vydali novou verzi a pushli to do všech zařízení. Nebylo by v pak lepší aplikací umožnit hlásit jako nakaženého i toho kdo nemá výsledek testu? Ideálně ale pokud pak negativní PCR test umožňuje zpětvzetí tohoto nahlášení.

[davidvavra]

Google/Apple umožňuje tyto aplikace pouze zdravotnickým organizacím právě z toho důvodu, aby byly garanty toho, kdo je nakažený a kdo ne. Nejde spoléhat na samotné hlášení uživatelů, je zde moc velké riziko zneužití, že by někdo systém zahltil falešnou pozitivitou. Proto vyžadujeme pozitivní test, resp. záznam v databázi Daktela, která toto eviduje.

[brozkeff]

Tak podle všeho tato možnost hlásit jen příznaky, a možnost alarm odvolat po negativním testu, existuje v rakouské aplikaci Stopp-Corona!

Viz https://www.austria.info/cz/servis-fakta/bezpecne-do-rakouska/aplikace-stopp-corona

Co znamenají červený a žlutý varovný stupeň?

Aplikace má dva varovné stupně. Žluté varování udává, že kontaktní osoba zaznamenala příznaky nemoci. Červené varování znamená, že někdo, s kým jste byli déle než 15 minut v užším kontaktu (pod dva metry), byl pozitivně testovaný.

Od aplikace také dostanete informaci, pokud je výsledek testu navzdory příznakům negativní.

Doporučuji prověřit to, jak to rakouská aplikace dělá, protože právě to by bylo i u české eRoušky mimořádně cenné zejména, není-li možné mít výsledky testování každého a včas.

[brozkeff]

@davidvavra

[davidvavra]

Mohu toto téma otevřít v teamu. Ale je to velká změna zasahující do mnoha částí aplikace, vývoj by byl náročný.

[Jazzz42]

Bylo by to fajn, protože pokud to trvá týden od návštěvy lékaře k obdržení výsledků, tak to snižuje účinnost aplikace. Obávám se, že je reálnější to celé přepsat, než donutit vládní nemehla, aby konečně po pů roce navýšila kapacitu testování.

\ rouškám zdar a elektronickým obzvlášť

[brozkeff]

Tak to vypadá, že podpora pro tyhle jiné stavy se objevila v EN API 1.5 a výše:

reportType (v1.5 and higher only)

Type of diagnosis that this key was uploaded with. We recommend that the app set this value before uploading each key to the server. The values range from 0 to 5 and have the following definitions. The app must handle all of these values without crashing if received from the server. 0: UNKNOWN. Report type metadata is missing from the diagnosis key. In v1.7 and higher, keys with report type set to UNKNOWN do not contribute to the risk value. 1: CONFIRMED_TEST. A medical provider has confirmed the user had a positive diagnostic test for COVID-19. 2: CONFIRMED_CLINICAL_DIAGNOSIS. A medical provider has confirmed the user had symptoms consistent with a COVID-19 diagnosis. 3: SELF_REPORT. The user has self-reported symptoms consistent with COVID-19 without confirmation from a medical provider. 4: RECURSIVE. This value is reserved for future use. 5: REVOKED. In v1.5, REVOKED is not used. In v1.6 and higher, REVOKED eliminates exposures associated with that key from the detected exposures. v1.6 supports changing the reportType value associated with a particular Temporary Exposure Key (TEK), allowing public health authorities (PHAs) to update reported cases to a more accurate state as more information is gathered. TEKs can go through a single report type transition, additional transitions will be rejected if more than one is attempted. The following transitions are supported: SELF_REPORT -> CONFIRMED_TEST, CONFIRMED_CLINICAL_DIAGNOSIS, REVOKED CONFIRMED_CLINICAL_DIAGNOSIS -> CONFIRMED_TEST, REVOKED

[brozkeff]

Nicméně i legacy v1 API pro to má/mělo různé stavy, jen vyjádřené v tomto atributu:

transmissionRiskLevel (Legacy v1 mode) Note: We strongly recommend migrating to ExposureWindow mode for enhanced risk calculation functionality.

In legacy v1 mode, specifies the level of risk of cross-exposure for the duration of the interaction between devices. The following are suggested uses. If used, your app should set this value before uploading each key to the server. 0: Unused 1: Confirmed test - Low transmission risk level 2: Confirmed test - Standard transmission risk level 3: Confirmed test - High transmission risk level 4: Confirmed clinical diagnosis 5: Self report 6: Negative case 7: Recursive case 8: Unused/custom This value is unused in ExposureWindows. See Transmission risk for more information.