Skal man lukke et sikkerhedshul, der kan hjælpe syge børn?
Det sikkerhedshul, som Version2 beskriver i dag, er blot endnu en måde at udnytte den svage, hjemmebyggede protokol bag firmaet Insulets Omnipod Eros-pumper på.
Protokollen har imidlertid også åbnet for, at hackere med gode hensigter har kunnet fifle med pumperne i deres stræben efter at bygge såkaldte closed loop-pumper, der kommunikerer med kontinuerlige blodsukkermålere og doserer insulin automatisk.
- emailE-mail
- linkKopier link

Fortsæt din læsning
- Sortér efter chevron_right
- Trådet debat
...i hvert fald skal de foreslåede API'er og deslige være tilgængelige førend man stopper produktionen af de usikre pumper - og desuden skal vi have tilpasset loop softwaren til dette API.
Som looper har jeg netop bestilt så manger usikre pumper som muligt, i frygt for at man vælger at stoppe produktionen i utide.
Jeg vil personligt hellere leve med risikoen for at blive hacket(læs: slået ihjel) end at leve uden muligheden for at loope.
Jeg tror at man skal være type1 diabetiker, for at forstå hvor stor en hjælp i hverdagen looping er, set i forhold til alt andet - og dermed også forstå, hvorfor jeg hellere vil leve med en usikker pumpe, end at skulle slås med manuelt insulindoseringsbøvl.
Men - der er en ny Omnipod undervejs.... Jeg forudser at vi bliver tvunget over i den nye og sikrere model, men samtidigt bliver tvunget til at fortsætte med at anvende en ikke kompatibel blodsukker sensor(Abbott Freestyle Libre). I så fald fratages vi muligheden for at kunne loope.
Den helt store afgørende forskel ved anvendelsen af loop kan observeres særligt i perioden fra jeg går i seng til jeg vågner om morgenen. Igennem hele natten er det tydeligt, hvorledes systemet natten igennem foretager korrektioner, således at jeg vågner med et nær perfekt blodsukker.
Som et mere tydeligt/konkret eksempel på forskellen i at leve med og uden looping er mit langtidsblodsukker:
Med looping: 51 mmol/mol Uden looping: 59 mmol/mol
Man kunne også have en pumpe, som tillod at man kommunikerede sikkert med den.
Først skal vi definere hvad vi mener med det. Handler det udelukkende om at implementere et interface, så de eneste der kan kommunikere med pumpen, er den som ejeren har intention om?
Eller skal der også være medicinsk sikkerhed? Med andre ord, skal jeg som hjemme-udvikler have mulighed for at lave en kodefejl, der giver en dødelig dosis insulin?
Man kunne lave en mellemting, hvor pumpen acceptere instruktioner, men der er grænser for hvad den acceptere. Det kunne være en maximal dosis pr. tidsrenhed - og rammer man den dosis er der tale om en fejl der giver en alarm og lukker for interfacet. Folk med mere viden indenfor området kan nok sætte bedre grænser. Men det burde man vel også have i den "manuelle" pumpe der laves i dag, så en decimalfejl i indtastningen kan blive fanget.
Det moralske dielemma mellem sikkerhedshuller og hjælp til syge børn, bygger på et falskt præmis:
Først og fremmest kræver det en pumpe, der kan kompromitteres
Man kunne også have en pumpe, som tillod at man kommunikerede sikkert med den. Altså via en offentlig dokumenteret protokol, der understøttede anstændig sikkerhed, herunder kryptering og autentifikation. Og naturligvis med mulighed for at tilføje egne brugere.
Det burde være et krav til alt kommunikerende medicinsk udstyr.
Hullet skal lukkes, og der skal etableres et API. Så simpelt er det.
Producenten kunne evt. etablere et officielt interface.
Der er ingen tvivl om at det hul skal lukkes. Medicinsk udstyr, inkl. software, skal igennem en meget hård godkendelsesprocess. Det er der en grund til, for hvad hvis et stykke software går i et loop og begynder at tømme insulinbeholdningen? Hvad hvis en hukkommelsesfejl får ganget dosis med 8?
Personligt har jeg brændt et dyrt spejlreflekskamera af pga en fejl i noget 3.parts firmware, der gav flere funktioner. Det vil jeg ikke risikere med et menneske.