Vaikka laite näyttäisi matalaa AHI- lukua (taitaa tosin negatiivinen BIAS olla AS11 laitteella keskimäärin -14,3 ja pahimmillaan -32,2 tutkimusten perusteella... helvetin epätarkka softa), niin silti siellä voi olla flow rate (epätasainen hengitysgraafi) ja flow limit graafeilta nähtäviä tapahtumia, jotka eivät ihan yllä 50%:n asti (tai joita laite ei merkkaa), mutta jotka voivat laskea happisaturaatiota alle optimin. Ja siihen päälle jos AHI-luku on vaikka 0,5 tapahtumaa/h, niin todellisuus voi olla yli 10 tapahtumaa/h.
Selvennyksenä vaikka apneaa kutsutaan hengityskatkokseksi, niin laite rekisteröi apnean (ei aina, kuten yllä mainitsin tuosta virhemarginaalista) silloin kun flow rate (eli ylähengitystiet kuristuvat) tippuu yli 75%:n. Suomeksi siis sisään- ja uloshengityksen litramäärä tippuu 75% normaalista. Hypopnean laite merkkaa silloin kun flow rate tippuu yli 50%:n. Kaikki tämän alle menevät ylähengitysteiden tukkeutumiset laite jättää merkkaamatta.
Tässä esimerkki erilaisista flow rate graafeista:
Tässä timestampilla merkattu juttu tutkimuksista missä tarkasteltiin eri laitteiden virhemarginaaleja AHI- lukujen osalta:
)
Päällisin puolin siis kaikki näyttäisi hyvältä (maski ei vuoda, AHI luku kunnossa jne), mutta loppupeleissä noiden ResMed laitteiden AHI- luvut ovat aikalailla mitä sattuu ja kaikista olennaisin asia lopulta kuitenkin on happisaturaation taso.
Jos sulla on hoitopaineen vaihteluväli esim. 4-16 ja unen aikana paljon noita flow limit tapahtumia joihin laite ei tietenkään reagoi, niin happisaturaatio voi tippua liian alas. Kone pitää sua vaikka tasolla 7 ja ei merkkaa tapahtumia, mutta silti hapen virtaus voi olla vaikka 48% rajoittunutta. Varmasti vaikuttaa negatiivisesti happisaturaatioon ja unenlaatuun laajemminkin.
Tässä lisää juttua tuosta flow limit- teemasta:
En siis itse haluaisi luottaa pelkästään tuohon AHI- lukemaan ja laitteen automaattiseen hoitopaineen säätöön tietyllä välillä. Parhaimman hoitovasteen saa nyt nopean perehtymiseni perusteella happisaturaation mittauksella, flow limit ja flow rate graafien tutkimisella ja sen jälkeen sopivan hoitopainevälin säätämisellä datan perusteella. Eli se alin säädetty hoitopaine varmasti poistaa flow limit- graafilta nähtävät tapahtumat ja flow rate normalisoituu. Ja turha sitä hoitopaineen ylärajaa on pitää liian korkealla. ResMedin algo on tosi agressiivinen ja nostaa sen väkisin turhan korkealle käyttäjäkokemusten perusteella. Omaa dataa seuraamalla näkee minkälainen ylin hoitopaine riittää ja se varmasti parantaa unenlaatua ja käyttömukavuutta, kun ei tulee liikaa painetta väkisin läpi.
Lisämausteet soppaan tuo EDR-tasot ja käyttääkö Standard vai Soft- algoritmia. Se soft algo vaikuttaa tosi riskiseltä ja ResMed:n EDR toimii niin huonosti, että sun pitää säätää hoitopainetta 2-3 pykälää normaalia korkeammalle. Laite ei tee sitä automaattisesti.
Tässä asiasta lisää:
Voin toki olla väärässä, ihan uuden asian äärellä olen ja vasta muutaman päivän asiaa selvittänyt. Joku perehtyneempi korjatkoon, jos olen totaalisen väärässä.
Loppukaneettina uniapneahoidon perimmäinen tarkoitus on varmistua siitä, että unen aikana saat tarpeeksi happea (happisaturaatio) ja että saat levollista unta (yllä mainitut flow rate ja flow limit- jutut).
AHI- arvojen yksisilmäinen tuijotus ei ole hyväksi, vaikka tärkeä asia sekin.
Selvennyksenä vaikka apneaa kutsutaan hengityskatkokseksi, niin laite rekisteröi apnean (ei aina, kuten yllä mainitsin tuosta virhemarginaalista) silloin kun flow rate (eli ylähengitystiet kuristuvat) tippuu yli 75%:n. Suomeksi siis sisään- ja uloshengityksen litramäärä tippuu 75% normaalista. Hypopnean laite merkkaa silloin kun flow rate tippuu yli 50%:n. Kaikki tämän alle menevät ylähengitysteiden tukkeutumiset laite jättää merkkaamatta.
Tässä esimerkki erilaisista flow rate graafeista:
Tässä timestampilla merkattu juttu tutkimuksista missä tarkasteltiin eri laitteiden virhemarginaaleja AHI- lukujen osalta:
)
Päällisin puolin siis kaikki näyttäisi hyvältä (maski ei vuoda, AHI luku kunnossa jne), mutta loppupeleissä noiden ResMed laitteiden AHI- luvut ovat aikalailla mitä sattuu ja kaikista olennaisin asia lopulta kuitenkin on happisaturaation taso.
Jos sulla on hoitopaineen vaihteluväli esim. 4-16 ja unen aikana paljon noita flow limit tapahtumia joihin laite ei tietenkään reagoi, niin happisaturaatio voi tippua liian alas. Kone pitää sua vaikka tasolla 7 ja ei merkkaa tapahtumia, mutta silti hapen virtaus voi olla vaikka 48% rajoittunutta. Varmasti vaikuttaa negatiivisesti happisaturaatioon ja unenlaatuun laajemminkin.
Tässä lisää juttua tuosta flow limit- teemasta:
En siis itse haluaisi luottaa pelkästään tuohon AHI- lukemaan ja laitteen automaattiseen hoitopaineen säätöön tietyllä välillä. Parhaimman hoitovasteen saa nyt nopean perehtymiseni perusteella happisaturaation mittauksella, flow limit ja flow rate graafien tutkimisella ja sen jälkeen sopivan hoitopainevälin säätämisellä datan perusteella. Eli se alin säädetty hoitopaine varmasti poistaa flow limit- graafilta nähtävät tapahtumat ja flow rate normalisoituu. Ja turha sitä hoitopaineen ylärajaa on pitää liian korkealla. ResMedin algo on tosi agressiivinen ja nostaa sen väkisin turhan korkealle käyttäjäkokemusten perusteella. Omaa dataa seuraamalla näkee minkälainen ylin hoitopaine riittää ja se varmasti parantaa unenlaatua ja käyttömukavuutta, kun ei tulee liikaa painetta väkisin läpi.
Lisämausteet soppaan tuo EDR-tasot ja käyttääkö Standard vai Soft- algoritmia. Se soft algo vaikuttaa tosi riskiseltä ja ResMed:n EDR toimii niin huonosti, että sun pitää säätää hoitopainetta 2-3 pykälää normaalia korkeammalle. Laite ei tee sitä automaattisesti.
Tässä asiasta lisää:
Voin toki olla väärässä, ihan uuden asian äärellä olen ja vasta muutaman päivän asiaa selvittänyt. Joku perehtyneempi korjatkoon, jos olen totaalisen väärässä.
Loppukaneettina uniapneahoidon perimmäinen tarkoitus on varmistua siitä, että unen aikana saat tarpeeksi happea (happisaturaatio) ja että saat levollista unta (yllä mainitut flow rate ja flow limit- jutut).
AHI- arvojen yksisilmäinen tuijotus ei ole hyväksi, vaikka tärkeä asia sekin.
Viimeksi muokattu:
