[Joerg Moeller]

Gestern habe ich mir nach monatelanger SiDiary-Abstinenz die Version 6 installiert, um zu sehen, ob - nach meinem Umstieg auf ein CGMS - SiDiary doch eine Alternative zur unübersichtlichen CoPilot-Software ist ... und wurde leider total enttäuscht:

Vielleicht wäre es nicht dazu gekommen wenn du nicht monatelang abstinent gelebt hättest. Wie du ja weißt haben wir die Beta-Phase nicht nur genutzt um das Programm zu testen, sondern auch um Feinschliff anzulegen. Und dabei wollten wir uns eben nicht allein auf unsere Glaskugel verlassen.  

Zudem mangelt es erheblich an Stabilität: Das Programm stürzt reproduzierbar ab, sobald ich den Tag wechsele (bei mir lief das Programm keine zwei Minuten am Stück bei etwa einstündiger Testung mit CGMS-Daten des Freestyle Navigators und Pumpendaten des ezmanagers/animas).

Könntest du uns deine Datenfiles aus SiDiary, dem CoPilot und dem ezManager mal an info@sinovo.net schicken? Dann können wir mal schauen was da los ist.

Vielleicht wäre es ein Ansatz für die weitere Entwicklung folgenden Ansatz zu verfolgen (nur ein kleines Gedankenspiel):
- Es können nicht alle Werte angezeigt werden und das ist auch nicht sinnvoll.
- Die Tagebuchansicht mit den Dokumentationsmöglichkeiten ist aber auch für CGMS-Nutzer unverzichtbar (ideal wäre ein Liniendiagramm über den in Spalten dokumentierten Ereignissen)!
- Wenn dies nicht mit dem derzeitigen Progamm möglich ist, dann gibt es folgende Alternative:
- SiDiary müsste eine sinnvolle Auswahl treffen bzw. berechnen.
- Eine solche wäre nach meiner Meinung:
1. Erfassung und Abbildung von deutlichen Extremwerten mit genauer Uhrzeit (also die Werte, bei denen die Tendenz des Blutzuckers jeweils dreht, von steigend zu fallend und umgekehrt, davon gibt es meist so 3-5).
2. Abbildung von Blutzuckerwerten, die zeitlich mit einem dokumentierten Ereignis zusammentreffen.
3. In den Zwischenzeiten, in denen weder deutliche Extremwerte noch Dokumentationen vorhanden sind, könnten halbstündige oder stündliche errechnete Durchschnittswerte die Tendenz einigermaßen abbilden.

Ja, das fände ich äußerst sinnvoll und das sollten wir unbedingt auf die (nach oben offene) ToDo-Liste setzen. Ich hätte dann aber gern die Durchschnittswerte aus Punkt 3 nicht im BZ-Block sondern als Datentyp. Im BZ-Block sollten nur tatsächlich gemessene Werte stehen, wie soll man sonst unterscheiden zwischen Extremwert aus 1. und Durchschnitt aus 3.?

[Joerg Moeller]

Diese Messtechnik wird vermutlich noch recht teuer sein. Wird so etwas von den Krankenkasssen bezahlt (Gesetzliche - bzw. Private Krankenkasssen)?

Falls ja, wäre es ein notwendiges Feature für SiDiary. Falls nein, ist es ein HighEnd Feature, das erst zukünftig für uns in der breiten Masse verfügbar sein wird.

Die Kassen tun sich noch schwer damit, weil diese Sensoren irre teuer sind. Dadurch kann es natürlich nicht die gleiche Priorität haben wie z.B. die Daten eines neuen unglaublich guten Messgeräts auszulesen. Aber ich denke trotzdem, daß SiDiary darauf vorbereitet sein sollte.
Immer mehr Kassen übernehmen die Kosten für CGMS (wenn auch noch nicht so viele, daß man von einem Erdrutsch sprechen könnte) und dadurch werden die Sensoren dann mit der Zeit auch billiger. Dadurch kommen noch mehr Bewilligungen usw.
Und der frühe (SiDiary-)Vogel fängt den Wurm

[RC23]

Weitere Messtechnik wird aktuell entwickelt, um indirekt BZ-Messwerte zu ermitteln.

"Die Solianis Monitoring AG ist eine medizinal-technische Firma, die Geräte entwickelt zur nicht-invasiven kontinuierlichen Blutzuckermessung für Diabetespatienten. Die Technologie beruht auf einer einmaligen und proprietären Multisensortechnik zur Überwachung physiologischer Parameter. Das nicht-invasive Solianis Gerät liefert Resultate, die vergleichbar sind mit den bereits FDA-bewilligten invasiven Geräten."
Quelle: http://www.insulinclub.de/showthread.php?t=14606

Auch hier sollte SiDiary Anschluß halten, um neue Technologien mitzunehmen. Bloß bis die oben genannte Technik einsatzreif sein wird, werden vermutlich noch zwei Jahre ins Land ziehen.

[Adrian]

Bloß bis die oben genannte Technik einsatzreif sein wird, werden vermutlich noch zwei Jahre ins Land ziehen.

Die, die schon mindestens 4 Jahre dabei sind, nennen das Ding "Pendra" ;-)
Also, wer glaubt an die 2 Jahre?

[Alf]

Hallo zusammen,

also ich denke es ist überhaupt nicht nötig, so eine Riesendiskussion zu entfachen mit "hätte wäre wenn und aber, Missverständnissen undundund".

Andreas hat da (völlig berechtigt) einen Makel entdeckt, den wir uns wie immer zur Brust nehmen werden. Systemabstürze sind ein absolutes NoGo und deshalb immer TopPrio 1 auf unserer Liste. Optimierungen, Verbesserungen usw. müssen wir aufgrund der vielen Anforderungen einfach auf einer ToDo-Liste einreihen und dafür die Prio bewerten. Speziell hier ist es so, dass unter anderem natürlich auch die Frage entscheidend ist: Wie viele Anwender betrifft das? Und das ist tatsächlich leider dann etwas bitter für diejenigen unter Euch, die schon ein CGMS haben, dass ihr doch sehr wenige seid verglichen mit den Dingen auf unserer Liste, die dann sehr viel mehr Anwender auf einen Schlag erreichen.

Wegen der Datenflut und wohin wird was importiert: Der Treiber erlaubt es schon jetzt bewusst, die Daten nicht als normale BZ-Werte zu importieren, sondern als CGMS-Datentyp. Wenn man zusätzlich diesen CGMS-Datentyp für die Tagebuchdarstellung unsichtbar schaltet (in der Maske der benutzerdefinierten Datentypen), kann man die Tagebuchmaske "wieder nutzen" und dann für Auswertungen zum Beispiel in den Statistiken die BZ-Datenquelle inkl. BE/Bolsu/Basal usw. einblenden und darunter die vollständige CGMS-Datenkurve als weitere Datenquelle.

Ich weiss das ist nicht optimal, war aber aufgrund der bisherigen Prioritäten der Workaround, der vom Aufwand her in der heissen Phase tragbar war und ein Darstellen der manuell protokollierten Werte im Einklang der automatisiserten Daten aus einem CGMS ermöglicht.

Eine Verdichtung der CGMS-Daten steht zusätzlich schon seit dem auf der Liste aber da will ich ehrlich sein: Im Moment geht es doch recht hoch her.

Wie Jörg schon gesagt hat: Gerne würde ich mich um die Systemabstürze zeitnah kümmern: Wenn Du mir da mit Deinen Daten behilflich wärst bin ich sicher, dass wir diese Kuh schnell vom Eis kriegen.

Und an alle anderen: Es freut mich, dass ihr so euphorisch seid aber ich bin zu lange in der IT tätig als dass ich nicht wüsste, dass selbst das best-ausgetestete Stück Software Macken haben könnte, die sich 99,99% der Anwender überhaupt nicht erklären können und die anderen 0,01% unweigerlich zu dem Schluss kommen, dass es sich um eine Riesen-Software-mülltonne handeln muss.

Dem kann man nur begegnen, dass man sich diesen Situationen stellt und versucht schnellstmöglich zu analysieren und zu helfen - ich denke zumindest in diesem Punkt können wir das glaubhaft von uns behaupten.

Viele Grüße, Alf.

[Joa]

Ha,

jetzt bin ich auch mal auf diesen Thread aufmerksam ge-(macht) worden.

Ich habe mich ja seit Monaten nicht mehr mit der 6er befasst. Und auch nicht mehr in der Beta-Abteilung mitgelesen. 

Das Thema mit Abstürzen im Zusammenhang des Importes von CGMS-Daten hatten wir ja auch schon. Was ja auch von Alf zügig aufgebessert wurde.
Wie üblich und gewohnt. 

In dem Zusammenhang kam es ja auch auf das Thema der völligen Unübersichtlichkeit aller Auswertungsvarianten von SD 6, wenn die SD 6 mit CGMS-Daten überfüttert wird.

Eine Lösung, d. h. eine sinnigere Darstellung und Verdichtung des CGMS-Datentsunamis hatte Alf für Version 6.xx der Final in den Plan aufgenommen.

Wenn Andreas nun bei seinem aktuellen Test sofort von SiDiary die blaue Karte gezeigt bekam, ist das vermutlich das geringste Problem. Das, so denke ich, wird Alf in altbewährter Art und Zuverlässigkeit lösen.

Spannender ist wohl die Frage, wie der Importfilter für CGMS-Daten arbeiten sollte, um letztlich analyserelevante Daten nicht zu verwerfen, aber auch nicht ein eher dürftiges Gemansche aus Durchschnittswerten je Zeitraum xy zu erzeugen (wie es z.B. beim Freestyle Navigator so zu finden ist).

Wobei natürlich auch solche Durchschnittswerte ihre Anwendung finden können.

Interessant wäre schon die Diskussion, welche Daten in welcher Bezugsverknüpfung relevant sind, und welche Daten ein Import- oder Darstellungsfilter aussondern darf/sollte/müsste. Schon damit SiDiary vor Überlastungen geschützt wird, und möglichst auch noch irgendwann komplett auf einem PPC die Analyse ermöglicht.

Insofern und überhaupt finde ich den Beitrag von Andreas hier ausgesprochen sinnvoll und nützlich, und nicht nur für User eines CGMS.

Auch wenn ich, als banaler CGMS-User und Andreas, als "Hochleistungsuser", sicher nur einen verschwindend geringen Anteil der Zielgruppe von SiDiary repräsentieren tun.

In Anbetracht dessen kann ich mir denn zwar dieses oder jenes wünschen, aber ich kann es auch in Verhältnisse setzen. Und Sinovo, oder auch Alf muss selber abschätzen, was seine Zielgruppe und sein Anspruch ist.

Klar, es wäre schön, wenn SiDiary alle Bedarfe erfüllen kann. Aber schauen wir uns an, was die Pharmaunternehmen da an Software zu präsentieren haben, dann ist das doch wirklich ausgesprochen dürftig.

@ MaKe: Vielleicht hältst Du Dich künftig aus Themen raus, bei denen schon die Überschrift Dir signalisiert, dass Du keinen blassen Schimmer hast?

Gruß
Joa