[Alf]

Wegen der Auswahl, einen UDT im Tagebuch anzuzeigen. Du redest hier zwar immer von den CGMS-Daten aber es geht bei der Funktionalität eben gar nicht speziell um CGMS, sondern allgemein um Daten, die in einem benutzerdefinierten Datentyp gespeichert werden. Und da die ja beliebig editierbar sind (ich habe im Tagebuch z.B. keine CGMS-Daten, dafür aber meine Schritte vom Schrittzähler) würde eine Abfrage zur Ein/Ausblendung von CGMS keinen Sinn machen: SiDiary weiss nicht mal, dass das CGMS-Daten sind, das sind an der Stelle beliebige Zahlenwerte und ist beim nächsten Anwender dann vielleicht die Häufigkeit der Toilettenbesuche

Wegen der Übernahme CGMS in BZ im Statistikfenster bin ich etwas skeptisch, denn auch hier zeichnet SiDiary das UDT-Diagramm ohne inhaltlich zu wissen, dass das darin BZ-Daten aus einem CGMS sind.
Halte ich in der Statistik zumindest für schwierig und sähe so etwas vielleicht eher in einem kleinen AddIn?

[Joa]

Wegen der Auswahl, einen UDT im Tagebuch anzuzeigen. Du redest hier zwar immer von den CGMS-Daten aber es geht bei der Funktionalität eben gar nicht speziell um CGMS, sondern allgemein um Daten, die in einem benutzerdefinierten Datentyp gespeichert werden.

Grundsätzlich schon klar, dass UserDefininierte Daten-Typen alle möglichen sein können.
Hier geht es um den vordefinierten DatenTyp "CGMS" über den ich konkret rede.

... ich habe im Tagebuch z.B. keine CGMS-Daten, dafür aber meine Schritte vom Schrittzähler

Jeder Schritt ein Datensatz?  

... würde eine Abfrage zur Ein/Ausblendung von CGMS keinen Sinn machen: SiDiary weiss nicht mal, dass das CGMS-Daten sind

Doch, sonst könnte SD die CGMS-Sätze nicht gezielt behandeln. Soweit ich verstehe, bekommt SiDiary dieses Wissen als Default in die Wiege gelegt und wird vom Importfilter mit der CGMS definierten Datenmilch dick&rund gepäppelt. 

... das sind an der Stelle beliebige Zahlenwerte und ist beim nächsten Anwender dann vielleicht die Häufigkeit der Toilettenbesuche

Was bei der nächsten Cholera-Pandemie dann sicherlich auch zu Darstellungsschwierigkeiten der Tagebuchansicht führen müsste. 

Wegen der Übernahme CGMS in BZ im Statistikfenster bin ich etwas skeptisch, denn auch hier zeichnet SiDiary das UDT-Diagramm ohne inhaltlich zu wissen, dass das darin BZ-Daten aus einem CGMS sind.

Nachvollziehbare Skepsis. Als Standard-Programmverhalten würden dann die Toilettenbesuche als Blutzuckerwert eingetragen. Oder was auch immer grade im UDT-Diagramm angewählt wurde.

Halte ich in der Statistik zumindest für schwierig und sähe so etwas vielleicht eher in einem kleinen AddIn?

Da spricht sicher nichts dagegen.
Wenn sich so ein AddIn denn auch noch in einem skalierbaren eigenen (PopUp) Window realisieren ließe?

Dann wäre das schon fast eine Verlockung. 

Gruß
Joa

[Alf]

Ok. Bleibt erst mal die Frage, wie die anscheinend zu Leerspalten führende Verknüpfung zum Datentyp CGMS verhindert werden kann.

Ich versuche das auch nochmal reproduzieren...

Das konnte ich eben eliminieren, kommt mit dem nächsten Update...

Doch, sonst könnte SD die CGMS-Sätze nicht gezielt behandeln.

Das ist der springende Punkt; SiDiary behandelt das nicht gesondert. Das ist ein beliebiger Datensatztyp wie jeder andere auch Lediglich der Importtreiber für den CoPilot und Carelink weiss dass das Sensordaten eines CGMs sind aber SiDiary als Applikation selbst weiss lediglich, dass es da einen Datentyp xyz (CGMS) gibt und dafür gespeicherte Werte (Es ist aber im Programm keinerlei Sonderbehandlung implementiert mit einer Unterscheidung: Wenn es Daten gibt vom Typ "CGMS" tue dies oder jenes.

Beim Laden des Tagebuchs wird einfach geschaut, welche UDTs möchte der Anwender als zusätzliche Zeilen im Grid sehen. Diese Daten werden aus der Datenbank eingelesen und ermittelt, wieviele Spalten sich daraus ergeben würden. Übrsteigt das das maximal Verdaubare kann nur die Datenliste kommen, passt es ins Grid, geht das Tagebuch auf. Ist aber inhaltlich völlig losglöst von CGMS-Daten. Könnte wie gesagt auch jeder andere Datentyp sein, für den einfach viele Werte gespeichert sind...

Gaaaanz vereinfacht, speichert SiDiary in der Datenbank die Daten in etwa so: Timestamp;Datensatztyp;Wert

Alle BZ-werte stehen dort als Datensatztyp 1 drin, alle Ereignisse als 2, BEs als 3 usw. (CGMS als UDT steht irgendwo ab 100+x drin)

Aus dieser einfachen Datenliste (die Maske kommt dem tatsächlich Gespeicherten auch schon recht nahe) wird dann quasi fürs Tagebuch wieder eine Art Pivottabelle aufgebaut und es sieht im Grunde so ähnlich aus wie in den früheren Versionen. Allerdings haben die früheren Versionen dieses X-Y-Raster des Grids eben auch im Speicherformat gehabt, das gibt's jetzt zugunsten wesentlich besserer Sync-Möglichkeiten nicht mehr...

[Joa]

... Leerspalten ...

... konnte ich eben eliminieren, kommt mit dem nächsten Update...

 

Und evtl. die CGM-Grafik auch unter der Verlaufsgrafik plaziert? Wäre dann möglicherweise eine Extra-Vorlage für CGMser?
Dann kann der Doc (das Diab-Team) auch gleich mal sehen, ob die Auswahlsystematik des Patienten der tatsächlichen Insulin + Stoffwechsellogik entspricht.

Gruß
Joa

[Alf]

Die Vorlagen nehmen wir nie ins Update-Package mit rein, weil's dort schnell zu "Versionskonflikten" kommen könnte. Normalerweise müsste die im Setup drinliegen; ich habe sie eben mal hier hochgeladen. Wenn Du dort einen 2. Platzhalter für die BZ-Verlaufsgrafik reinpackst müsste es das in etwas sein?!

[Rob]

Bisher mache ich alles mit Sidiary und bin völlig zufrieden. Nach meiner ersten schweren Hypo konnte ich über die Folgekostenargumentation meine private KV überzeugen die Sensoren und 60% des Freestyle Navigators zu übernehmen. Der kommt nun nächste Woche.

Was hat sich denn an der CGMS-Front getan? Ich habe mit Interesse die Beiträge von Alf, Joa und Andreas verfolgt. Ist das Datenmengen/-darstellungsproblem gelöst oder durch die Priorisierung nach unten gerutscht?

[Joerg Moeller]

Ich wüßte nicht daß es da ein Problem gibt

Viele Grüße,
Jörg

[Joa]

Ist das Datenmengen/-darstellungsproblem gelöst oder durch die Priorisierung nach unten gerutscht?

Hallo Rob,

dann hat die Hypo    ja auch was Gutes    gebracht. Also zumindest Glückpuntsch zum Navigator. 

Hinsichtlich der Datenmengen sollte man den Import der CGMS-Werte weiterhin als Datentyp CGMS realisieren, weil der Import als BZ-Werte weiterhin zur Unübersehbarkeit führt.

Wenn man aus den CGMS-Daten die markanten BZ-Werte extrahieren möchte, muss das weiterhin händisch erfolgen und ist somit etwas aufwändig, aber machbar. Am Besten scheint es mir weiterhin die Protokollierung der BZ-Werte fortlaufend mobil vom CGMS abzunehmen, wenn man Verläufe werten möchte.

Ich protokolliere allerdings schon wieder seit Monaten nix mehr. 
Und sonst ja auch eher nur rudimentär.

Gruß
Joa

[Rob]

Ich wüßte nicht daß es da ein Problem gibt

Jörg, ich meinte so etwas z.B. wie in dem von Andreas erstellten Fred:

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.
Mit dieser Lösung wären bei stündlicher Rundung ca. 24-35 Werte anzuzeigen (Rundungswerte, Extrema, Dokumentationswerte), bei halbstündiger Anzeige etwa 48-55 Werte nötig.
Das reicht zwar nicht ganz an ein Liniendiagramm samt Dokumentation heran, würde SiDiary aber wieder nutzbar machen. In der derzeitigen Form ist es das nach meiner Ansicht (nicht nur wegen der nicht vorhandenen Stabilität) nicht.

Danke Joa, das hatte ich auch so in den vorgehenden Posts verstanden. Was meinst Du mit:

Am Besten scheint es mir weiterhin die Protokollierung der BZ-Werte fortlaufend mobil vom CGMS abzunehmen, wenn man Verläufe werten möchte.

[Joerg Moeller]

Nein, eine weitergehende Auswertung von CGMS-Daten gibt es von unserer Seite bisher noch nicht. Falls jemand Programmierkenntnisse hat: das wäre ein Fall für ein AddIn, für die es ja aber der Version 6 eine offene Schnittstelle gibt.

Viele Grüße,
Jörg