Ik mag mijn Android-telefoon niet updaten van mijn insuline-app leverancier!

Een lezer vroeg me:

Een leverancier van een bloedglucose sensor (gebruikt door diabetici) heeft de mogelijkheid om een sensor uit te lezen via een app op een mobiele telefoon. Nu stelt deze leverancier dat, zodra er een update van de softwareversie van de mobiele telefoon beschikbaar is je dient te wachten met updaten tot zij hun app hebben geupdated. Dit om te voorkomen dat, door incompatibiliteit tussen de app en de nieuwe software versie, je meetdata kwijt bent. Op zich logisch, je hebt als diabeet met een reden een sensor en als er incompatibiliteit bestaat zal de app niet kunnen werken. Wie is alleen aansprakelijk als de telefoon besmet/geïnfecteerd/onbruikbaar raakt op het moment dat er wel een nieuwe softwareversie beschikbaar is maar de eindgebruiker deze nog niet geïnstalleerd heeft op verzoek van een app programmeur. Is dit in algemene voorwaarden van de app af te vangen en is dus de (vaak onbekwame eindgebruiker) zelf verantwoordelijk?

Op zich vind ik het heel netjes van die leverancier om zo expliciet te waarschuwen voor mogelijke incompatibiliteit. Het zou erg vervelend zijn als de app net niet goed meer werkte en daardoor gegevens verloren gingen, of nog erger onjuiste metingen worden gedaan.

Daar staat tegenover dat het natuurlijk onveilig kan zijn dat je je smartphone-software (je OS dus) niet kunt updaten, zeker als het gaat om een security update of iets anders kritisch. Het is minstens zo vervelend als er in dat tijdsinterval een of andere malware binnendringt en schade aanricht of gegevens steelt.

De wet zegt helaas niet waar de verantwoordelijkheid ligt bij dit soort zaken. Er is ook geen jurisprudentie over deze interactie tussen risico’s. De hele algemene regel is dat als je als dienstverlener je best doet om problemen te vermijden, je niet aansprakelijk bent als er desondanks eens iets misgaat (voor juristen: de zorgplicht van een goed dienstverlener, art. 7:401 BW).

Vanuit die algemene zorgplicht lijkt het mij dat deze leverancier bovenop de OS-updates moet zitten en moet zorgen dat er zo snel mogelijk een update aan de app komt. Gaat er in het dan nog overblijvende tijdswindow iets mis, dan zie ik niet hoe je de app-leverancier nog een juridisch verwijt kunt maken.

Voor mij weegt zwaar dat het zal gaan om iets dat zelden voorkomt, een korte periode van risico betreft en dat niet ieder gat automatisch grootschalig geëxploiteerd wordt met gevolgen voor de smartphone-eigenaren.

Ik zou wel verwachten dat verlies van data op meerdere manieren voorkomen wordt. Backups van oude datasets zijn toch vrij eenvoudig te maken?

Arnoud

12 reacties

  1. Aangezien het hier om software gaat die gegevens uit leest van een “medical device” zal er uitgebreide validatie van de app nodig zijn als er wijzigingen doorgevoerd worden (o.a.FDA regelgeving). Dit kan zomaar betekenen dat zelfs een kleine aanpassing in een complete her-validatie van de app resulteert. Ik ga er dan ook vanuit dat de fabrikant er wel bovenop zit, er is alleen voldoende tijd nodig voor de validatie.

  2. “moet zorgen dat er zo snel mogelijk een update aan de app komt” … dat “zo snel mogelijk” zou een leverancier concreet moeten maken: 1 week? 1 maand? 1 jaar?

    Leveranciers die zeggen “zo snel mogelijk” is namelijk vaak een formulering voor “geen idee, we hebben geen planning en geen menskracht”.

    Enne: Nieuwe Android-versies komen al eerder als Beta beschikbaar; dat kan de leverancier al testen.

    1. Als Micha gelijk heeft (uitgebreide validaties, ik ken deze app+sensor niet) dan ben je er nog niet met testen van de beta alleen. Die zal haast per definitie niet 100% gelijk zijn aan de def. versie, al was het qua versienummer. Zonder hele korte lijntjes met de OS-maker zal er dan tenminste een korte periode zitten tussen vrijgave van def. OS-update en def. app-update (namelijk de laatste verificatie en dan pas vrijgave). Ook als het in 99,99% van de gevallen goed gaat op de oude versie, gaat het in 0,01% vd gevallen fout en dat is best veel als er 1000 mensen van afhankelijk zijn (dan iets meer dan 10% dat het fout gaat).

      Dat neemt echter niet weg dat de app prima rekening kan houden met normale updates. Inclusief maken van backups die ook zijn terug te zetten op een nieuwe versie. En duiding van afwijkende waarden als de OS-update opeens foute meetwaarden zou doorgeven. Risico op dataverlies door niet updaten lijkt me al snel groter..

  3. Dus je mag het niet updaten omdat je mogelijk meetdata kwijt raakt?!? Dat is toch een kwestie van niet alles lokaal opslaan of regelmatig back-uppen? Wat gebeurt er dan als je je telefoon kwijt raakt of stuk raakt? Dan ben je die gegevens ook onherroepelijk kwijt dus? Maar dat is voor de fabrikant blijkbaar geen probleem… Nee, die update, daar raak je data door kwijt?

    Vreemd verhaal dus…

  4. Ik vraag mij wel af wat de programmeur in de code uitspookt waardoor de app opeens niet meer compatible zou zijn. Als je gewoon netjes code schrijft binnen de specificaties van Android zou je geen problemen moeten hebben. Maar als je ongedocumenteerde functies gaat gebruiken of andere, twijfelachtige, code dan vraag ik mij af of je als programmeur wel goed bezig bent.

    Het enige twijfelachtige wat ik hier kan bedenken is de hardware-aansluiting van de sensor. Maar als die sensor gewoon Bluetooth gebruikt verwacht ik zelfs daar geen problemen mee.

    En ik snap al helemaal niet waarom de app data zou verliezen. Die data staat immers in de Cloud of in een lokaal bestand en ik zou niet weten waarom deze data “spontaan” verwijderd zou worden.

    Ik zou deze apparatuur dus per direct terugsturen en mijn geld terugvragen als een leverancier dit van mij vereist. Immers, ik moet mijn telefoon gewoon kunnen updaten ongeacht de apps die ik heb. En de apps horen te blijven werken. Zoniet, dan is dat niet conform mijn verwachtingen…

    1. Ik ken de specifieke architectuur van de glucosemeter/telefoon combinatie niet, maar het zou me niet verbazen als daar een (android/linux) device driver voor nodig is. Nu is de interface voor device drivers (op vijwel alle besturingssystemen) minder stabiel (backward compatible) dan de interface voor toepassingsprogramma’s. Er is een grotere kans op compatibiliteitsproblemen voor een device driver en daarom is het niet vreemd dat de sensorleverancier bij iedere android release tijd inruimt foor testen en bug fixes.

      Ja Wim, device drivers gebruiken functies die voor een web-programmeur obscuur zijn. Dat is omdat je op een totaal ander nivo met de computer werkt.

      1. Ik ben goed bekend met device drivers en heb er vaak genoeg mee moeten werken. Maar ik vraag mij af hoe lastig deze eigenlijk zijn onder Android. Als de sensor via Bluetooth werkt, zou er geen probleem moeten zijn als je gewoon standaard libraries gebruikt.

        Android heeft de User Drivers die je kunt gebruiken. Dat is waar je als developer mee mag werken en Google moet er dan voor zorgen dat deze blijven werken. En sensors op Android vragen ook weinig moeite. Maar goed, dit is allemaal Android for Things. In het algemeen heeft Android duidelijke voorschriften voor hardware-makers om te volgen. Wie daarvan afwijkt heeft dus het risico om uiteindelijk niet meer compatible te zijn. Mogelijk dat hun sensor niet door de Android Compatibility test heen komt. Mag de gebruiker niet de dupe van worden…

        1. Er zijn verschillende type sensoren in gebruik, continue glucosemeters (CGM) en flash glucosemeters (FGM). CMG lijkt me duidelijk, die meten continu (ik neem aan via Blue Tooth). Bij FGM moet je je telefoon of een scanner bij de sensor houden om deze uit te lezen, deze verbinding zal vaak via NFC zijn.

          Zover ik weet zijn er voor zo goed als alle CGM en FGM sensoren ook stand-alone scanners beschikbaar, het is dus niet zo dat er geen alternatief is.

  5. Volgens mij is dat gewoon een kwestie van aansprakelijkheid afdekken, voor het geval dat… Is deze app wellicht ook in de VS op de markt? Daar is de strategie naar consumenten toe sowieso van: “Waarschuw maar voor zoveel mogelijk, dan kan je altijd de klant de schuld geven als er iets misgaat.” De punative damages kunnen daar ook abnormaal hoog zijn… Waarschijnlijk gaat er in 99,9% van de Android updates niks mis met deze app en de meetgegevens.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.