Rettet unsere DIY LOOP SYSTEME

  • bierernst

    Hat den Titel des Themas von „Rettet unsere DIY LOOP SYSTEM.“ zu „Rettet unsere DIY LOOP SYSTEME“ geändert.
  • killler23436 hat dort auch erlaubt/erwünscht zitiert...




  • Sorry, war vorhin im Stress und hatte wenig Zeit dafür. Aber dank heikeov ist es ja nun komplett.


    Danke dir heikeov :blume<3


    Wenn ich kann bin ich immer nett. Bin ich nicht nett, kann ich gerade nicht. 8o




    DanaRS 08/19 - nightscout 10/19 - Dexcom G6 + AAPS + xdrip 11/19 - Closed Loop 02/20 - SonyXA2 - SonySWR50



    Generation X / Generation Golf und Digital Immigrant

  • Ist erledigt.


    Gibts dazu nen Blogpost oder ähnliches? Ich verstehe den groben Kontext (Cybersecurity als Vorwand, den Datenaustausch zwischen Geräten weiter zu verschließen). Aber gibts dazu ne Übersicht, was genau passieren würde, wenn das durchgeht?


    Z.B. die Dash-Implementation in AAPS ist ja komplett inoffiziell, ebenso die BYODA-Geschichte. Welche Cybersecurity-Maßnahmen würden da im Raum stehen, die diese "Zugriffsarten" blockieren würden? Und könnten solche Maßnahmen überhaupt in den momentanen Stand der bereits zugelassenen Geräte implementiert werden? Oder wird es sich um zukünftige Geräte drehen, die dann später erst auf den Markt kommen?


    Der originale Text ist ja doch heftiger Corporate-Sprech und dazu noch auf nicht dem leichtesten Englisch.

  • Wenn ich das richtig verstanden habe geht es darum das Zugriffsmöglichkeiten dicht gemacht werden auf Daten von Pumpen, Messgeräten, ..... aufgrund von Cybersecurity Gründen?
    Das würde dann bedeuten das für DIY kein Zugriff mehr auf die Daten möglich ist und damit DIY nicht mehr mögliche ist.

  • na ja, nicht mehr möglich... es muss ja eine Schnittstelle zur Weiterverarbeitung geben, sonst blieben die Daten ja im Sensor stecken und nützen Niemandem mehr, also ist es (theoretisch) auch wieder hackbar. Die Frage ist, wie groß der Aufwand ist und wie groß die Frusttoleranz bei den Entwicklern ist, das auch zu tun *örks*


    Dann sollen sie halt EINE vernünftige Software entwickeln und alle Pumpen und Sensoren damit kompatibel machen, dann nehm ich auch einen kommerziellen Loop

    Blutzucker ist die Autobahn, Gewebszucker ne Nebenstraße!

  • Das Draft von der FDA für diese Guideline findet sich übrigens hier:


    https://www.fda.gov/media/119933/download


    Liest sich erstmal wie'n Stein.


    Ich schau da mal später rein, aber solche Dokumente sind echt schwer zu interpretieren, wenn man nicht zu 100% in der Materie steckt. Und selbst wenn, wird man eigentlich für das Lesen von so nem Teil amtlich bezahlt.

  • Dann sollen sie halt EINE vernünftige Software entwickeln und alle Pumpen und Sensoren damit kompatibel machen, dann nehm ich auch einen kommerziellen Loop

    Sehe ich auch so... bis auf den letzten Satz. 😉


    Dann werde ich erst einmal keinen kommerziellen Loop nutzen.

    Dann bleib ich bei Dexcom, Dana mit AnyDanaApp.


    Und überlege ob man nicht eine Sammelklage anstreben kann.


    Warum dürfen Unternehmen auf meine Daten zugreifen und ich nicht? Und damit meine ich alle Daten, die wir ohne der Anstrengungen von freien Entwicklern gar nicht wüssten.


    Ich nehme an, das sich da ein paar Hersteller Gedanken gemacht haben, wie sie uns noch mehr, die von Szaladin benannten Steine in den Weg legen könnten. Und ihre eigenen Systeme, die es ohne DIY wohl gar nicht gäbe oder zumindest noch nicht gäbe eher an den Patienten brächten.


    Ich bin schon wieder auf 180 und mein BZ auch...

    *grummel*

    :devil:


    Wenn ich kann bin ich immer nett. Bin ich nicht nett, kann ich gerade nicht. 8o




    DanaRS 08/19 - nightscout 10/19 - Dexcom G6 + AAPS + xdrip 11/19 - Closed Loop 02/20 - SonyXA2 - SonySWR50



    Generation X / Generation Golf und Digital Immigrant

  • na ja, nicht mehr möglich... es muss ja eine Schnittstelle zur Weiterverarbeitung geben, sonst blieben die Daten ja im Sensor stecken und nützen Niemandem mehr, also ist es (theoretisch) auch wieder hackbar. Die Frage ist, wie groß der Aufwand ist und wie groß die Frusttoleranz bei den Entwicklern ist, das auch zu tun *örks*


    Dann sollen sie halt EINE vernünftige Software entwickeln und alle Pumpen und Sensoren damit kompatibel machen, dann nehm ich auch einen kommerziellen Loop

    Ich sehe die Idee hinter offen Schnittstellen ganz klar aber ich verstehe auch das die Firmen das nicht machen.

  • Soweit ich das sehe, sind die offenen Schnittstellen sowieso in der Minderheit. Meiner Kenntnis nach sind nicht viele Pumpen so offen wie z.B. die Dana.


    Die Dash (link) und wohl auch die Tandem sind ACE-enabled, das weiß ich.


    Es scheint ja hauptsächlich die DIY-Loops zu betreffen, die offene Schnittstellen nutzen, die gewollt offen sind. Ich wär jetzt mal so frei zu behaupten, dass die meisten DIY-Loops (abgesehen von den komplett so gewollten Pumpen wie Dana) irgendwelche Lücken nutzen oder sich als Steuergeräte "ausgeben". Da das sowieso keine geplanten Lücken sind, werden diese durch die Guidance Notes gar nicht erfasst.


    Was passieren könnte, wäre, dass die Entwickler bestehende Sicherheitslücken von einer Systemversion zur nächsten schließen. Aber sowas kann jederzeit auch ohne die FDA Guidances passieren.


    Allgemein müsste man mal schauen, ob was für einen Dokumentenentwurf es hier geht (link):

    Zitat

    About FDA Guidances

    Guidance documents represent the Agency's current thinking on a particular subject. They do not create or confer any rights for or on any person and do not operate to bind FDA or the public. An alternative approach may be used if such approach satisfies the requirements of the applicable statute, regulations, or both. For information on a specific guidance document, please contact the originating office. Another method of obtaining guidance documents is through the Division of Drug Information.

    Es handelt sich also bei den Guidances um weniger strenge Dokumente als z.B. Gesetze. Aber sie spiegeln die "Politik", die die FDA (auch bei Zulassung) sich auferlegt, wieder. Sie entsprechen also ein bisschen auch dem Charakter einer Norm (Standard). Da aber die FDA auch Normen veröffentlicht, wäre die Wortwahl wohl etwas falsch.


    Zu viel darf an den Geräten im Nachhinein auch nicht geändert werden, ohne dass eine erneute Zulassungsprüfung oder eine Art Delta-Review gemacht werden muss. Daher müsste man sich mit der Weltuntergangsstimmung auch etwas zurückhalten können.


    Cybersecurity ist ein großes Thema in der Industrie. Für manche Wirtschaftsfelder gibt es keine normativen (also ISO-Normen, EN, etc) Regulierungen, denen man in Sachen Cybersecurity folgen muss. Für den Automotive-Bereich z.B. hat sich erst in den letzten 10 Jahren was getan (IEC_62443, etc), manches sogar erst letztes Jahr.


    Ich habe die FDA-Guideline, um die es hier geht, bisher nur überflogen. Aber soweit ich das seh (oberflächlich, wirklich!) scheint es hauptsächlich darum zu gehen, dass Cybersecurity-Aspekte in die Entwicklung und Zulassung von medizinischen Geräten einfließen sollen. Für vernünftige Cybersecurity müssen eine Menge strikte Vorkehrungen getroffen werden, was an sich auch sinnvoll ist. Leider beißt sich vernünftige Cybersecurity leider mit vielen Bequemlichkeiten aus dem Alltag.

    Hier mal aus der Einleitung. So ein SPDF (link) ist an sich sinnvoll. Ich bin mit dem Vorläuferkonzept SDLC nicht vertraut, aber solche Vorgänge machen sinn. Problem ist nur, dass wir fürs Loopen halt Schwachstellen ausnutzen. Ein DIY-Looper nutzt u.U. die selben Einfallswege wie ein Hacker.


    Jetzt bin ich beim Tippen doch ins Dokument gegangen. Args. Hier meine Einschätzung soweit (ohne Gewähr):

    1. Introduction, Scope, Background (Formalitäten) (Seite 1-3)
    2. General Principles (Quasi die Einleitung, warum CySec wichtig ist, weitere Formalitäten) (Seite 4-7)
    3. SPDF (ein Framework, an dem mach lang entwickeln kann - quasi eine Box an Werkzeugen und Prozessen, die in der Entwicklung eines Geräts genutzt werden müssen oder sollen, damit genügend Cybersecurity gewährleistet wird) wird vorgestellt. Hier müsste man schauen, was relevant ist. Vermutlich nicht viel, da dies nur neu entwickelte Geräte betrifft. (Seite 8-16)
    4. Security Architektur (eine weitere Forderung an die medizinischen Geräte) (Seite 16-20)
    5. Security Testing (relevant für die Entwicklung, nicht für den Endnutzer) (Seite 22-23)
    6. Security Transparenz (Hab ich noch nicht angeschaut) (Seite 24-27)
    7. Anhänge (noch nicht angeschaut)

    Wichtig wäre zu wissen:

    • Müssen solche Guidelines bei bestehenden Zulassungen (also die Geräte, die wir momentan benutzen) im Nachtrag erfüllt werden, um die FDA-Zulassung zu behalten? Oder gilt sowas erst bei Neuzulassungen?
    • Wie pflanzt sich so eine FDA-Guidance überhaupt in die EU-Zulassung fort?
    • Es gibt Geräte, die explizit offen konzipiert sind (die DANA zum Beispiel). Da müsste man schauen, wie die Entwickler da vorgehen. Für Looper mit Geräten, die sowieso offen ausgelegt sind, seh ich erstmal keine Sorge solange die Entwickler diese Richtung beibehalten wollen. Für kommerzielle Loops, wo die Entwickler eh Schnittstellen sicher bauen müssen, wird sich vermtl. eh nix ändern.

    Für die DIY-Looper seh ich die Probleme hauptsächlich auf Seite 28 unter "Authentication":

    Die meisten DIY-Loops nutzen ja die Schwäche, sowohl dass die Herkunft einer Information/Befehls (meist AAPS, OAPS, Loop) als auch der Befehl selbst eigentlich als "fremdartig" erkannt werden müsste.


    Natürlich gilt auch der Satz hier:

    Zitat

    On a technical level, the strength of a device’s authentication scheme is defined by the amount of
    1070 effort, including time, that an unauthorized party would need to expend to identify the
    1071 decomposition of the authentication scheme

    Stimmt schon, aber meist investieren die Loop-Entwickler mehr Zeit in das knacken eines Systems als jemand, der sich einen Geldvorteil erhofft. Kann natürlich am Ende so sein, dass die Cybersecurity-Hürden nicht so hoch angesetzt werden wie man zunächst befürchtet. Sicher ist kaum ein System, es geht nur darum, das Knacken so lang dauern zu lassen, dass es sich finanziell nicht "lohnt", den Aufwand zu betreiben. Mal abwarten.

  • Danke für die Einsichten!

    Tja ändern wird unsere Mailing Aktion wohl auch nicht so viel.

    Wir können also nur abwarten und hoffen...


    Wenn ich kann bin ich immer nett. Bin ich nicht nett, kann ich gerade nicht. 8o




    DanaRS 08/19 - nightscout 10/19 - Dexcom G6 + AAPS + xdrip 11/19 - Closed Loop 02/20 - SonyXA2 - SonySWR50



    Generation X / Generation Golf und Digital Immigrant

  • Es gibt Geräte, die explizit offen konzipiert sind (die DANA zum Beispiel). Da müsste man schauen, wie die Entwickler da vorgehen. Für Looper mit Geräten, die sowieso offen ausgelegt sind, seh ich erstmal keine Sorge solange die Entwickler diese Richtung beibehalten wollen.

    Im schlimmsten Fall ist es IME-DC nicht mehr erlaubt, die Schnittstelle so offen zu konzipieren. Dann wären wirklich alle betroffen.


    Aber ich bleibe erstmal gelassen und setzt auf unsere AAPS-Programmierer. Bis jetzt sind alle Pumpen und CGMS steuerbar geworden, egal wie verschlüsselt.

    :blume


    LG

    zuckerstück

    Wir sind hier nicht bei Wünsch-dir-was, sondern bei So-Isses 8o

  • Sicherheitsvorkehrungen sind ja eigentlich dafür da, um zu verhindern, dass eine Software unberechtigterweise manipuliert werden kann. Das bedeutet aber nicht, dass die von der Software verarbeiteten oder erzeugten Daten nicht ausgelesen werden können/dürfen bzw. an eine Schnittstelle zur Verfügung gestellt werden. Die Schnittstelle kann ja technisch als Einbahnstraße ausgelegt werden. Die Befürchtung ist nur, dass die Hersteller unter dem Deckmantel der Cybersicherheit den Zugriff auf die Daten zusätzlich erschweren.


    Der Diabetologe Dr. Frank Best hatte mal auf Diatec einen Beitrag zum Thema „Wem gehören die Daten“ gepostet, der leider nicht mehr online ist. Deshalb füge ich den Beitrag unten als Anhang bei. Darin findet man folgendes:


    Dabei hat sich der G-BA bei der Zulassung von rt-CGM-Geräten unmissverständlich ausgedrückt:

    MVV_RL §3 Abs. 6: „Soweit der Einsatz des Gerätes eine Verwendung, Erhebung,

    Verarbeitung oder Nutzung personenbezogener oder personen-beziehbarer Daten vorsieht, muss sichergestellt sein, dass diese allein zum Zwecke der Behandlung der Patientin oder des Patienten erfolgen und eine Nutzung ohne Zugriff Dritter, insbesondere der Hersteller, möglich ist.“

    Was bedeutet das? Nun, wenn man einflussreich ist, über die finanziellen Mittel

    verfügt und eine gute Lobby hat, dann kann man sich auch schon mal über Regeln

    hinwegsetzen. Das fördert sicher nicht das Vertrauen in demokratische

    Spielregeln. Man könnte auch sagen, das ist asozial.


    Wem gehören die Daten - diatec Kommentar Frank Best.pdf