Diabetesinfo-Forum
SiDiary => Allgemeines => Thema gestartet von: Joa am November 13, 2009, 21:35
-
Hallo zusammen,
so, ich habe aus gegebenem Anlass mal wieder SiDiary aus der Versenkung geholt und war sehr erfreut (nun auch schon mal) zu registrieren, dass Alf zwischenzeitlich eine erste Lösung zum Handling von CGM-Daten eingebaut hat, die ich auch ausgesprochen gelungen und pragmatisch sinnvoll finde. :super: :super: :super:
Ein Problem ergibt sich allerdings, wenn ich die Druckvorlagen benutzen möchte, um das Protokoll zu Papier zu bringen.
Die CGM-Daten für den BZ(BG) werden in Sidary, wenn entsprechend eingestellt, als eigenes Ereignis (Event) behandelt.
Am Beispiel des Novo-Protokolls als Druckvorlage führt das dazu, dass im Protokoll massenweise leere Spalten zwischen den Spalten mit Daten erscheinen, so dass die Spalten für 24 Stunden sich über etwa 6 Seiten hinquälen.
Kann ich das mit einfachen Mitteln selbst abstellen, oder müssten da entweder in den Vorlagen oder in SD selber entsprechende Manipulationen/Änderungen/Optionseinfügungen erfolgen? :kratz:
Danke vorab für Hilfestellungen. :rotwerd:
Gruß
Joa
-
Nachtrag:
Also beim Novo-Protokoll Ausdruck wird wohl für jeden vorhandenen Event eine Zeitspalte eingefügt. Bei irgendwelchen anderen Ausdrucken auch noch.
Ausdrucke, die das Protokoll auf 24 Spalten - je Stunde eine Spalte - beschränken, zeigen den Effekt (natürlich) nicht.
Dazu dann noch die Frage, wie sich die Grafik des Verlaufs der CGM-Daten in einen Ausdruck einfügen lässt? :kratz:
Viele Grüße
Joa
-
Hallo Joa,
ich denke das Aufblähen der Ausdrucke nach dem CGMS-Import liegt weniger an den als CGMS-Datentyp importierten Werten aus Deinem Navigator, sondern, dass im Rahmen dieses Imports auch diverse "Zeitslot"-Infos impotiertiert wurden (die ganzen T-Events, die auch im Tagebuch zu sehen sind), die Abbott CoPilot ebenfalls bereitstellt.
Die CGMS-Daten erscheinen ja nicht als Event, sondern als zusätzlicher Datentyp, so dass man ihn im Tagebuch auch ausgeblendet lassen kann.
Dafür spricht auch, dass das Novo-Tagebuch-Template so explodiert und die 24H-Templates nicht: Die 24H-Templates haben nämlich keine Zeile für die Ereignisse... ;)
D.h. Wenn Du die Novo-Tagebuchvorlage präferieren würdest, könntest Du dort die Ereignis-Zeile im Template herauslöschen oder aber nat. auch grundsätzlich die Ereignisse beim Import aus Copilot "abwählen", so dass die gar nicht ins Tagebuch kopiert werden (nach dem CoPilot-Import in SiDiary einfach die untere Option vor der Übernahme ins Tagebuch nehmen und dann dort die Ereignis-Kategorie abwählen).
Wegen des Ausdrucks für die UDT-Daten: Da kannst Du aktuell nur den Direktdruck aus der Statistikmaske verwenden. Den Platzhalter für eine Verlaufskurve analog zu den Labordaten müssen wir als Template noch abbilden... :rotwerd:
Viele Grüße, Alf.
-
Hallo Alf,
ich wähle grundsätzlich: "als GGMS-Daten importieren". Was bislang auch funzte.
ich denke das Aufblähen der Ausdrucke nach dem CGMS-Import liegt weniger an den als CGMS-Datentyp importierten Werten aus Deinem Navigator, sondern, dass im Rahmen dieses Imports auch diverse "Zeitslot"-Infos impotiertiert wurden (die ganzen T-Events, die auch im Tagebuch zu sehen sind), die Abbott CoPilot ebenfalls bereitstellt.
Kann ich nicht mitvollziehen. Im Tagebuch sind da keine T-Events zu sehen. Und in der Auswahl, welche Daten beim Import übernommen werden sollen ist nur 1 Event zu finden. Auch wenn der Import von Events abgewählt wird, kommt es seit heute (16.11.) dazu, dass der Import die Tagebuchansicht nur noch als Liste aufmacht, weil SD meint, dass zu viele Daten vorhanden seien.
Vermutlich das gleiche Problem wie bei der Novo-Vorlage, die ja die 10-minütigen Mittlungswerte vom Navigator importiert.
Irgendwo ist die Trennung zwischen CGM-Daten und dem Rest des Datenbestandes löchrig? :kratz:
Es scheinen die T-Events des CGM ein Hintertürchen zu finden?
Was denn möglicherweise aus der Analyse der Nov0-Templates ersichtlich wird?
Gruß
Joa
-
Hi Joa,
Irgendwo ist die Trennung zwischen CGM-Daten und dem Rest des Datenbestandes löchrig?
Es scheinen die T-Events des CGM ein Hintertürchen zu finden?
nee, jetzt geht's grad ein bisschen durcheinander... :zwinker:
Die CGMS-Daten haben definitiv nichts mit den Ereignis-Daten zu tun. Das ist in der Datenbank voneinander gekapselt abgelegt.
Mach doch mal bitte die Datenliste auf und schau dort nach, was am 16.11. für Daten vorhanden sind. Grundsätzlich kann nat. auch jede andere Datenkategorie dazu führen, dass die Tagebuchansicht nicht mehr dargestellt werden kann. Da geht's ja drum, dass das Grid dann einfach nicht mehr Spalten verträgt, egal ob diese Spalten wegen vieler Daten in der CGMS-Zeile, BZ-Zeile oder sonstwoher stammen...
Ich habe eben übrigens noch schnell die Vorlage für die UDTs umgesetzt; das kommt dann mit dem nächsten Update... :)
Viele Grüße, Alf.
-
Naaaben (gähn) Alf,
Es scheinen die T-Events des CGM ein Hintertürchen zu finden?
nee, jetzt geht's grad ein bisschen durcheinander... :zwinker:
Die CGMS-Daten haben definitiv nichts mit den Ereignis-Daten zu tun. Das ist in der Datenbank voneinander gekapselt abgelegt.
[/quote]
Glaub ich wohl auch, dass es ein bisschen durcheinander ging. Entwirrt sich aber so laaangsam.
Offenbar richtet sich die SiDiary Druck- und Exportabteilung immer nach den Einstellungen des Statistikfensters?
Ist für dieses die Darstellung des CGM-Grids aktiv, bekommt jeder CGM-Datenpunkt einen T-event im gedruckten Protokoll zugeordnet, dem aber der zugehörige CGM-Wert dann nicht zugewiesen wird.
Muss man erst mal drauf kommen. :zwinker:
Ich danke für die hilfreiche Anregung. :super:
Aber das nächste, vorgeblich siebensieglig scheinende Rätsel hat sich auch schon gezeigt. Demnächst mehr...
Gute Nacht
und
Gruß
Joa
-
Ich fürchte, das musst Du mir nochmal erklären. Habe ich schlichtweg nicht verstanden... :staun:
Wenn es diesbezüglich eine Korrelation zwischen Statistikfenster und Drucken gibt, wäre das nicht beabsichtigt und falsch...
-
Ich fürchte, das musst Du mir nochmal erklären. Habe ich schlichtweg nicht verstanden... :staun:
Also ich denke/erinnere, dass ich Drucken in die NovoStyle Vorlage aufgerufen haben.
Wenn im Statistikfenster die CGMS-Ansicht im Zusatzfenster aktiviert war, gab es im Ausdruck für jeden CGMS-Glucosewert leere Zeitspalten. Entsprechend der Wertmittlung des FSN alle 10 Minuten eine.
Bei deaktivierter CGM-Darstellung in der Statistik (Verlaufsgrafik) war alles fein.
Und das jeweils für den Druck des gleichen Zeitraums. So meine ich jedenfalls (erst mal).
Allerdings kann ich das heute nicht mehr reproduzieren kann, nur noch leere Spalten drin, es sei denn, es sind noch keine CGMS-Daten importiert, muss ich in Betracht ziehen, evtl. bei meiner vorgehenden Beobachtung diese doch mit unterschiedlichen Zeiträumen gemacht zu haben? :kratz:
Ok. Bleibt erst mal die Frage, wie die anscheinend zu Leerspalten führende Verknüpfung zum Datentyp CGMS verhindert werden kann.
Eine Frage die sich möglicherweise auch auf das Tagebuchfenster erstrecken könnte, weil dieses seit gestern bei mir nicht mehr angezeigt wird, nach dem letzten CoPilot-Import. Zu viele Daten... :staun: Daher nur noch Listenansicht.
Wenn der Tag keine CGMS-Datensätze enthält, geht natürlich das Tagebuch auch wieder.
Zu der weiter vorher gestellten Frage nach den in der Datenliste enthaltenen Datensätzen. In der Liste tauchen die CGMS Daten immer auf.
Es sei denn ich wähle den Filter ab. Was allerdings nicht zu speichern geht.
Gruß
Joa
-
Hi Joa!
Sidiary und CGMS Daten sind konträre Dinge!
Probleme entstehen nicht nur beim Ausdruck, sondern auch:
- Sidiary importiert den Insulintyp falsch ( immer als Bolus)
- Es ist nicht möglich, diesen zu editieren, weder Local noch bei Sidiary-online
- Beim Import als BZ werden jeder 2. bis 3. Wert weggelassen
- Synchronisierung mit Onlineserver bringt immer eine Fehlermeldung, Daten sind aber vollständig da.
Gruss Klaus
-
Sidiary und CGMS Daten sind konträre Dinge!
Uiuiui, na jetzt muss ich doch mal reingrätschen...! :zwinker:
Sidiary und CGMS Daten sind konträre Dinge!
Probleme entstehen nicht nur beim Ausdruck, sondern auch:
- Sidiary importiert den Insulintyp falsch ( immer als Bolus)
a) Ein Bolus hat nun so gar nichts mit einem CGMS zu tun - das liefert ja schliesslich "nur" Blutzuckerdaten
b) Für einen falsch zugeordnete Insulingabe müssten wir dann erst einmal klären, aus welchem Datenbestand Du importierst (CoPilot vs. Carelink)? Und wenn es dort klemmt, melde Dich doch einfach mal bei uns am Support - das hilft manchmal wirklich: Probleme von denen wir wissen, können wir oftmals sogar beheben ;)
c) Für den Fall, dass es sich um Copilot-Daten handelt und Du uns evtl. mal eines Deiner Datenfiles zur Verfügung stellen könntest, wäre das super, denn da hatten wir neulich schon einmal jemanden am Support, der das beim CoPilot-Import bemängelte, sich aber danach leider nicht wieder gemeldet hat... :nixweiss:
Es ist nicht möglich, diesen zu editieren, weder Local noch bei Sidiary-online
Nur damit ich das verstehe: Du kannst bei Dir importierte Bolus-Werte nicht editieren??? Da bin ich um so mehr an den Begleitumständen interessiert, denn ich wüsste nicht einen Grund warum das nicht gehen sollte.
Beim Import als BZ werden jeder 2. bis 3. Wert weggelassen
Das ist per Design so, wenn Du das Häkchen für den Dublettencheck nicht rausnimmst, denn genau das passiert dort: Ähnliche BZ-Werte, die in rascher zeitlicher Folge kommen werden als Dubletten verworfen. Einfach den Haken rausnehmen...
- Synchronisierung mit Onlineserver bringt immer eine Fehlermeldung, Daten sind aber vollständig da.
Kannst Du das näher spezifizieren? "Welcher Fehler"?
-
Allerdings kann ich das heute nicht mehr reproduzieren kann, nur noch leere Spalten drin, es sei denn, es sind noch keine CGMS-Daten importiert, muss ich in Betracht ziehen, evtl. bei meiner vorgehenden Beobachtung diese doch mit unterschiedlichen Zeiträumen gemacht zu haben? :kratz:
Dann würde ich sagen "Beobachtungsphase" einleiten. ;)
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...
Eine Frage die sich möglicherweise auch auf das Tagebuchfenster erstrecken könnte, weil dieses seit gestern bei mir nicht mehr angezeigt wird, nach dem letzten CoPilot-Import. Zu viele Daten... :staun: Daher nur noch Listenansicht.
...zumindest das aber sollte sich doch durch die Listendarstellung klären lassen: Wenn an dem Tag, den das Tagebuch nicht mehr darstellen kann entsprechend viele (zu viele) Daten vorhanden sind wäre es "as designed"
Setz Dir doch in der Listendarstellung einfach mal einen Filter auf den gleichen Tag wie der, der sich im Detail-Tagebuch nicht mehr darstellen lässt und dann als anzuzeigender Datentyp in der Liste nur BZ, BE, Bolus usw. -OHNE CGMS-Datentyp. Wenn sich dann die Liste eher kurz präsentiert, müsste das Tagebuch eigentlich aufgehen (und dann mail mir doch bitte infach mal das MOnatsfile und schreib mir den Tag dazu). Wenn die Datenliste aber dann auch schon lang ist, hast Du evtl. mal versehentlich doch CGMS-Daten als BZ-Werte importiert?
Viele Grüße, Alf.
-
Hallo Alf,
also ich habe noch ein wenig herumgespielt.
Die Darstellung der Tagebuchansicht hat nichts mit dem Erscheinen von CGMS-Daten in der Tagebuchliste zu tun.
Wenn die Tagebuchansicht nicht mitspielt, spielt sie NIE mit, sobald CGMS-Daten vorhanden sind (wo natürlich i.d.R. dann über 100 Datensätze CGM drin sind.
In der Contour-USB Installation zeigt sich weiterhin das Tagebuch, und der Aufruf der List zeigt auch die ebenfalls vorhandenen CGMS-Datensätze. Sogar nicht nur des Tages, sondern für einen Monat. Aktuell 17.10-17.11..
Beim SD-Stick zeigt die Liste ebenso die CGMS-Sätze an, aber ggf. (oder überhaupt?) nur einen Tag.
Filter ich die CGM-Sätze weg und wechsle zum Tagebuch, bleibt es bei keiner Ansicht.
Ich glaub, ich lade mal die beiden Sticks auf den Webspace, damit Du das mal in Toto nachvollziehen kannst.
Auch der Wechsel der SD.INI's, vom Contour zum Stick, ändert nichts.
Ist da 'ne Laufmasche im Programmcode versteckt? Oder bin ich so genial, SD den Boden weg zu schießen. :kratz:
Ich trau mir ja ne Menge zu. :patsch:
Wenn die beiden Installationen online sind, bekommst Du eine entsprechende Mail.
Gruß
Joa
-
Hi Alf,
Zuerst einmal möchte ich mich für meinen harten Beitrag entschuldigen, aber als schreibfauler Typ habe ich aufgeraft und eine lange Liste an Fehlermeldungen an den Support geschickt. Mit der Antwort von Jörg war ich nicht sonderlich zufrieden, es hatte den Anschein, ich solle Ruhe geben.
Zu den Fragen:
Es handelte sich um den Freestyle Navigator. Dieser unterscheidet "Insulin" in kurz-, mittel- und langwirkend. Dies steht so auch im Exportfile. Sidiary ignoriert diese Angaben und macht daraus "Bolus". Editieren lässt sich alles, nur "Bolus" lässt sich nicht in "Basal" ändern.
Den Datenfile von Oktober, der sich nicht fehlerfrei synchronisieren lässt, hatte ich mitgeschickt.
Auch ein Copilot-Exportfile mit Insulinangaben hatte ich schon mal geschickt.
Beim Import hatte ich selbstverständlich den Dublettencheck ausgeschaltet, sonst müssten noch viel mehr Werte fehlen.
Alles weitere morgen per e-mail
Gruss und Dank Klaus
-
Die Darstellung der Tagebuchansicht hat nichts mit dem Erscheinen von CGMS-Daten in der Tagebuchliste zu tun.
Wenn die Tagebuchansicht nicht mitspielt, spielt sie NIE mit, sobald CGMS-Daten vorhanden sind (wo natürlich i.d.R. dann über 100 Datensätze CGM drin sind.
Sorry Joa aber ich verstehe wieder nur die Hälfte von Dir ;)
a) Wenn CGMS-Daten als BZ-Daten importiert sind wird das Tagebuch in aller Regel die Anzeige verweigern und die Datenliste aufgehen, weil es zu zu vielen Spalten kommt.
Wenn CGMS-Daten als CGMS-Datentyp importiert wurden, muss man unterscheiden:
b) Das Tagebuch wird dann aufgehen, wenn der CGMS-Datentyp aktuell im Tagebuch _nicht_ angezeigt werden soll.
c) Wenn Du in der Bearbeitungsmaske der benutzerdefinierten Datentypen das Häkchen für CGMS setzt heisst das, die CGMS-Daten werden fürs Tagebuch eingelesen und das führt nat. in Konsequenz wieder zu Fall a)
Und genau hier _könnte_ dann vielleicht auch der Unterschied zwischen Deinen beiden Sticks liegen? Das ist dann auh keine Einstellung in einer ini, sondern das ist Bestandteil der Patienten-Datenbank (genauer die SiDiaryUDT.dat). Deshalb machte es auch keinen Unterschied, dass Du die ini umkopiert hast.
Filter ich die CGM-Sätze weg und wechsle zum Tagebuch, bleibt es bei keiner Ansicht.
Verstehe ich nicht :'( was heisst "bleibt es bei keiner Ansicht?" Wenn Du damit meinst, dass Du den Filter der Datenliste einstellst (ohne CGMS) und dann Deine Erwartungshaltung ist, dass das Tagebuch den Filter von der Datenlist berücksichtigen würde kommen wir nicht zusammen... ;) Bitte die einzublendenden UDTs fürs Detail-Tagebuch in der Maske der UDTs konfigurieren...
Ich glaub, ich lade mal die beiden Sticks auf den Webspace, damit Du das mal in Toto nachvollziehen kannst.
Schau doch bitte mal, ob auf dem einen Stick vielleicht der CGMS-Datentyp fürs Tagebuch auf sichtbar steht und auf dem anderen Stick nicht. Wenn ja ist das Phänomen damit ja geklärt (und Du kannst es dort umstellen), wenn es das nicht ist, reicht es aus, das Patienten-Stammverzeichnis und den CFG-Ordner zu zippen (von beiden Sticks) und zu mailen; das letzte Mal war das übers Web doch etwas problematisch und so groß sollten die gezipten Daten noch nicht sein!?
Auch der Wechsel der SD.INI's, vom Contour zum Stick, ändert nichts.
Ist da 'ne Laufmasche im Programmcode versteckt? Oder bin ich so genial, SD den Boden weg zu schießen. :kratz:
Ich trau mir ja ne Menge zu. :patsch:
Siehe oben, ini bringt's an der Stelle nicht aber ich glaube schon, dass wir das noch ergründen können... ;)
-
Zuerst einmal möchte ich mich für meinen harten Beitrag entschuldigen,...
Das ist überhaupt nicht nötig! Aber da diese Beiträge nat. völlig frei ins Web wandern, kann ich das so dann auch nicht unkommentiert stehen lassen - zumal es wie sich ja jetzt schon teilweise rausstellt da doch das ein oder andere Misverständnis gibt.
...aber als schreibfauler Typ habe ich aufgeraft und eine lange Liste an Fehlermeldungen an den Support geschickt. Mit der Antwort von Jörg war ich nicht sonderlich zufrieden, es hatte den Anschein, ich solle Ruhe geben.
Sorry aber das mag ich eigentlich auch so wieder nicht stehen lassen! Ich habe sowohl Deine Anfrage als auch Jörgs Antwort gelesen (weil er mich eh zu dem ein oder anderen Punkt vor seiner Antwort befragen musste). Ich habe das sicher nicht mehr im einzelnen im Gedächtnis aber Deine Fehlerliste enthielt ja nicht nur Fehler, sondern auch diverse Kommentare, Anmerkungen und Anregungen.
Immer dann wenn es um Features geht haben wir jedoch das Problem, das sich manches einfach nicht so umsetzen lässt, dass danach alle glücklich sind. Da müssen wir einfach intern bewerten, was geht und wie können wir eine möglichst große Gruppe mit etwas treffen/glücklich machen.
Ich erinnere mich z.B. an den Punkt Führungslinien auf der X-Achse, die Du zu anderen Uhrzeiten haben wolltest und es Dich gestört hat, dass die erste und letzte Führungslinie nicht angezeigt wird? Und das als Beispiel ist halt ein sehr spezielles Feature und wir werden es nicht schaffen, dass jeder mit den Führungslinien glücklich wird. Deswegen hat er wenn ich mich recht erinnere, die Möglichkeiten aufgezeigt, die man an der Stelle in SiDiary hat: Führungslinien lassen sich grundsätzlich sichtbar/unsichtbar schalten plus die Pointer-Einstellung mit der man sich seine eigene Führungslinie an der Mausposition ziehen kann.
Zusätzlich hatte er für einige Punkte um weitere Infos gebeten, um Fehlersituationen nachstellen und reproduzieren zu können. Auch die Ausführlichkeit seiner Antwort kann ich nicht zum Anlass nehmen, dass er Dich abbügeln wollte, im Gegenteil: Er schreibt bestimmt nicht sonderlich gerne lange Support-Emails... ;)
Ich denke damit können wir's aber auch bewenden lassen: Wir haben def. ein Interesse daran, Fehler zu eliminieren und den Anwendern zu helfen. Wenn wir dazu die nötige Unterstützung bekommen versandet das bei uns garantiert nicht...wenn Dir seine Antwort in irgendeiner Form aufgesäuert ist, tut mir das nat. leid aber Dich abzubügeln war bestimmt nicht sein Ziel. :nein:
Es handelte sich um den Freestyle Navigator. Dieser unterscheidet "Insulin" in kurz-, mittel- und langwirkend. Dies steht so auch im Exportfile. Sidiary ignoriert diese Angaben und macht daraus "Bolus".
Ah jetzt ja, dann geht's hier um den gleichen Support-Call, den ich zum Thema "CoPilot-Insulingaben-Import" noch in Erinnerung hatte: Wie damals schon geantwortet: Wir haben einen recht beträchtlichen Fundus an Copilot-Files aber in _keiner_ dieser Datei tauchen Informationen zu Insulintypen auf. Deswegen unterscheidet der CoPilot-Import-Filter an der Stelle auch nicht. Wenn wir da Insulintypen ausmachen können, ist das eine Kleinigkeit den Import zu erweitern!
Editieren lässt sich alles, nur "Bolus" lässt sich nicht in "Basal" ändern.
Ok, das hörte sich so an, als könntest Du keine Bolus-Werte editieren. Bolus und Basal sind an der Stelle nat. gar nicht die Nutzinformation des Datensatzes, sondern der "Datensatztyp" und der lässt sich in der Tat in der Datenliste absolut gewollt nicht editieren, denn dann ändert vielleicht noch jemand einen Blutzuckerdatensatz in eine BE-Gabe um oder ähnliches; das macht an der Stelle keinen Sinn.
Lass uns doch vielleicht einfach den Import-Filter mit Deinen Zusatzinfos erweitern, dann ist das Ändern überhaupt nicht nötig. ;)
Den Datenfile von Oktober, der sich nicht fehlerfrei synchronisieren lässt, hatte ich mitgeschickt.
Das konnten wir seinerszeit bei uns nicht reproduzieren. Die Vermutung war, dass es möglicherweise beim Online-Transfer zu einem Timeout kommen könnte, da Du auch berichtet hattest, dass Du etwas "schwachbrüstig" angebunden bist?
Auch ein Copilot-Exportfile mit Insulinangaben hatte ich schon mal geschickt.
Schick mir das doch bitte noch einmal zur Sicherheit zu. Ich habe im Home-Office nicht Vollzugriff auf die Support-Mails, schaue aber dort morgen auch nochmal nach. Vielleicht ist das Attachment in der Viruswall hängengeblieben.
Beim Import hatte ich selbstverständlich den Dublettencheck ausgeschaltet, sonst müssten noch viel mehr Werte fehlen.
Mail mir doch bitte eine konkrete Situation mit durch, wo Du im CoPilot-File BZ-Werte siehst, die in SiDiary nicht importiert wurden - die finden wir schon! ;) Ich tippe aber trotzdem noch auf den Dublettencheck... :wech: Der ist schon rel. ausgefeilt und berücksichtigt sowohl Abweichung des BZ-Wertes als auch Toleranzen für ein Zeitfenster für eine Dublette (aber das finden wir sicher schnell raus)
Alles weitere morgen per e-mail
Gerne! :ja:
Viele Grüße, Alf.
-
a) Wenn CGMS-Daten als BZ-Daten importiert sind wird das Tagebuch in aller Regel die Anzeige verweigern und die Datenliste aufgehen, weil es zu zu vielen Spalten kommt.
Das war es nicht. :nein:
Wenn CGMS-Daten als CGMS-Datentyp importiert wurden, muss man unterscheiden:
b) Das Tagebuch wird dann aufgehen, wenn der CGMS-Datentyp aktuell im Tagebuch _nicht_ angezeigt werden soll.
c) Wenn Du in der Bearbeitungsmaske der benutzerdefinierten Datentypen das Häkchen für CGMS setzt heisst das, die CGMS-Daten werden fürs Tagebuch eingelesen und das führt nat. in Konsequenz wieder zu Fall a)
:ja: Das wars!
Allerdings ist das Angebot die CGMS-Daten im Tagebuch zusätzlich zu protokollieren mehr als zweischneidig? Eher schon kontraproduktiv für CGMS-User? Um nun nicht von Stolpersteinen zu sprechen?
Ich entsinne meiner ehemaligen Erfahrung in früher Beta-Phase, als die Tagebuchansicht (Novo-Style) ewig lang wurde, und keinen Überblick bot, weil ja alle CGM-Daten angezeit wurden.
Nach meinem Neueinstieg habe ich nun nicht erwartet, dass die Anzeige einfach nur eine Höchstzahlbegrenzung bekommen hat.
Und in der Maske für Datentypen fehlt ein Hinweis, dass CGM-User, oder User die sonstwas alles protokollieren möchten, mit einer Höchstspaltenanzeige am Bildschirm rechnen müssen, die dann eine Listenansicht erzwingt.
Wie wäre es mit einem Popup bei Auswahl vom CGMS-Datentyp?
Danke für's "auf die Sprünge helfen", dass aber für solche DAU-User wie meinereiner zwingend notwendig ist. :patsch:
Btw. bemerkt, bei einem Vergleich der beiden UDT.Ini Dateien lassen sich Unterschiede denn auch nicht annähernd vermuten.
Ich vermute das ist unter
[Header]
...
CS=...... irgendwie geschlüsselt?
Nochmals Dank für Hilfestellung und
gut's (rausch- und pfeifarmes) Nächtle
Gruß
Joa
-
Ups, noch ein kleiner Nachtrag:
Was ich ziemlich klar vermisse ist ein Schalter zum gezielten Auslösen einer Synchronisation mit den vordefinierten Geräten.
Bisher habe ich den nur darin gefunden, SD nur auf Sync. beim Beenden zu stellen, und dann halt bei einer gezielt gewünschten Synchronisation zu beenden und neu zu starten.
Natürlich ist der neue Sync der 6 dem ollen 5er haushoch überlegen. Aber wenn ich weiß wann ich da syncen tu, kann ich das doch besser alles überschauen. Und notfalls nun sogar ggf. wieder rückgängig machen! :super:
Gruß
Joa
-
Hallo Joa,
ich behaupt auch nicht, dass die Aufbereitung der CGMS-Daten in irgendeiner Form der Weisheit letzter Schluss wäre. Wir hatten damals schon darüber gesprochen, dass man ggf. die CGMS-Daten verdichten müsste als z.B. stündliche Mittelwerte, sofern sich in einer Stunde nichts Dramatisches in die eine oder andere Richtung verändert hat aber eine solche Funktion ist bislang noch nicht umgesetzt. Deswegen war ich auch anfangs etwas irritiert, dass Du Dich über die "Änderungen" fürs CGMS so gefreut hast, denn da gibt es eigentlich keine Neuerungen.
Die Begrenzung der Tagebuchansicht auf eine max. Spaltenanzahl hat nichts mit CGMS zu tun, sondern ist schlichtundergreifend eine technische Limitierung des Tabellen-Controls! (Und für mein persönliches Dafürhalten macht auch die Tagebuchdarstellung bei z.B. 100 Spalten nicht mehr so arg viel Sinn, da der Hauptvorteil "alles auf einen Blick" durch das erforderliche Blättern verloren geht)
Die Auslagerung der importierten CGMS-Daten in einen CGMS-Datentyp erlaubt es aber zumindest die übliche Tagebuchansicht zu verwenden, wenn man den CGMS-Datentyp (wie per Default voreingestellt) im Tagebuch weglässt und zusätzlich in den Statistiken BZ-Kurve (inkl. BE/Boli usw.) in Zusammenhang mit der CGMS-Kurve zu sehen und zu analysieren...
Wegen des Syncs: Der Sync ist in den Masken, wo man potentiell Daten erfassen kann temp. unterbrochen. Wenn man die mittlere Sync-Option aktiviert (Sync im laufenden Betrieb), läuft gemäß des eingestellten Intervalls der Sync dann immer autom. los, wenn man in einer Maske ist, wo keine Daten erfasst werden, also z.B. die Statistik, Trend usw.
Im Tagebuch verändern sich dann auch die Sync-Statussymbole in der Statusbar und Du kannst dort z.B. auf das mobile Gerät klicken und trotzdem den Sync anzuwerfen.
-
Auch ein Copilot-Exportfile mit Insulinangaben hatte ich schon mal geschickt.
Schick mir das doch bitte noch einmal zur Sicherheit zu. Ich habe im Home-Office nicht Vollzugriff auf die Support-Mails, schaue aber dort morgen auch nochmal nach. Vielleicht ist das Attachment in der Viruswall hängengeblieben.
Habe nochmal alle Mails von Dir gecheckt aber ein CoPilot-File mit Insulinangaben konnte ich nicht finden. Die letzte EMail zu dem Thema war von Jörg mit der Bitte um Zusendung der Daten...
Ich habe von Dir ein älteres, kleines CoPilot-File von Dir in den Mails gefunden (das hattest Du in einem anderen Zusammenhang gemailt bevor Jörg nochmal darum gebeten hatte) aber dieses File enthielt ebenfalls nichts von unterschiedlichen Insulin-Kennzeichnungen (habe das gerade nochmal geprüft)!
Bitte mail mir das doch noch mal zu und dann schauen wir, wie wir den Filter erweitern können.
-
ich behaupt auch nicht, dass die Aufbereitung der CGMS-Daten in irgendeiner Form der Weisheit letzter Schluss wäre. Wir hatten damals schon darüber gesprochen, dass man ggf. die CGMS-Daten verdichten müsste als z.B. stündliche Mittelwerte, sofern sich in einer Stunde nichts Dramatisches in die eine oder andere Richtung verändert hat aber eine solche Funktion ist bislang noch nicht umgesetzt. Deswegen war ich auch anfangs etwas irritiert, dass Du Dich über die "Änderungen" fürs CGMS so gefreut hast, denn da gibt es eigentlich keine Neuerungen.
War für mich jedenfalls neu, dass die CGMS-Daten in einem eigenen Chart unterhalb der Verlaufsgrafik eingeblendet werden können.
Vielleicht hab ich da früher nur was übersehen/nicht gewusst?
Auf alle Fälle finde ich das schon eine deutliche Verbesserung. :super:
Um das mal weiter zu spinnen...
Wenn eine Form von Bearbeitenmodus dabei wäre, die bei einem Klick auf einen Datenpunkt im CGM-Chart denselben als BZ-Wert dupliziert, könnte man vielleicht sehr geschickt die (nach eigener Einschätzung) therapierelevanten Verlaufsdaten dort übernehmen? :kratz:
Die Begrenzung der Tagebuchansicht auf eine max. Spaltenanzahl hat nichts mit CGMS zu tun, sondern ist schlichtundergreifend eine technische Limitierung des Tabellen-Controls!
Da habe ich noch dunkel ewig lange Tagebuchdarstellungen mit der Beta im Sinn? :kratz:
Oder ist das wieder mal ein Hinweis, dass mein Alzheimer so langsam in die halluzinatorische Phase driftet? :staun:
... für mein persönliches Dafürhalten macht auch die Tagebuchdarstellung bei z.B. 100 Spalten nicht mehr so arg viel Sinn ...
Meine vollste Zustimmung! :ja:
Die Auslagerung der importierten CGMS-Daten in einen CGMS-Datentyp erlaubt es aber zumindest die übliche Tagebuchansicht zu verwenden, wenn man den CGMS-Datentyp (wie per Default voreingestellt) im Tagebuch weglässt und zusätzlich in den Statistiken BZ-Kurve (inkl. BE/Boli usw.) in Zusammenhang mit der CGMS-Kurve zu sehen und zu analysieren...
Ok, wo ich das jetzt auch geschnallt habe. :super:
Wie schon gesagt fehlt gehört da m. E. noch ein Popup hin, ggf. zur Bestätigung der CGM Auswahl für das Tagebuch.
Bzw. scheint diese Wahlmöglichkeit von vornherein widersinng.
Warum kann ich das Auswählen, wenn ich die Auswahl hinterher nicht darstellen kann?
Ok. Es könnte Sinn machen, wenn für ein CGMS (noch) kein Importfilter verfügbar ist, um so die Datensätze händisch als CGM-Daten zu importieren. Weil dann wären diese ja von vornherein komprimiert, in oben angegebenem Sinn.
Wahrscheinlich müsste man dann allerding die Werte auch zugleich als BG-Wert eintragen?
Wegen des Syncs: ....
Danke. Muss ich noch mal näher begrübeln. :zwinker:
Gruß
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. 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 ;D ;)
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?
-
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? :kreisch: :lachen:
... 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. :gruebeln:
... das sind an der Stelle beliebige Zahlenwerte und ist beim nächsten Anwender dann vielleicht die Häufigkeit der Toilettenbesuche ;D
Was bei der nächsten Cholera-Pandemie dann sicherlich auch zu Darstellungsschwierigkeiten der Tagebuchansicht führen müsste. :duck:
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. :nein:
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. :gruebeln:
Gruß
Joa
-
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...
-
... Leerspalten ...
... konnte ich eben eliminieren, kommt mit dem nächsten Update...
;D :super:
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
-
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?!
-
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?
-
Ich wüßte nicht daß es da ein Problem gibt :kratz: :ka:
Viele Grüße,
Jörg
-
Ist das Datenmengen/-darstellungsproblem gelöst oder durch die Priorisierung nach unten gerutscht?
Hallo Rob,
dann hat die Hypo :-\ ja auch was Gutes :D gebracht. Also zumindest Glückpuntsch zum Navigator. :zwinker:
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
-
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.
-
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
-
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.
Das meint, mit einem mobilen Gerät möglichst fortlaufend mitzutracken. Also alle relevanten Aktionen und Werte direkt in ein mitgeführtes Gerät (SmP, PPC, etc) einzugeben, und dabei die als dokumentationsrelevant gesehenen CGM-Werte auch.
Das ist so wie so die effektivste Art, den Stoffwechselverlauf zu optimieren, weil das Tracken der Werte zum Zeitpunkt der therapeutisch relevanten Entscheidung dazu führt, dass die Entscheidung selber in ihrem Kontext bewertet wird.
Gruß
Joa
-
Du schreibst dir also entscheidungsrelevante CGMS Werte als BZ Werte auf?
-
Ich glaube CGMS-Daten tagebuchrelevant zu verdichten ist von der Logik her simple. Im Navigator kann man ja auch BE, Sport und Insulingaben vermerken.
Hätte man kein CGMS würde man vor dem Essen (+Sport), nach dem Essen (+Sport) und vor der Basalgabe einen Wert messen. Also kann man die BZ-Werte doch tagebuchgerecht zu den Zeitpunkten der Ereignisse:
(1) BE-Aufnahme
(2) postprandial als Usereinstellung
(3) zu Insulingaben, wenn BE Event und Insulinevent > SEA auseinanderliegen (Korrektur)
(4) Sport-Anfang
(5) Sport-Ende
(6) Sport-Ende +x
(7) Mindestabstand von BZ Messungen 4h
aus der CGMS-Kurve übernehmen. Anders würde man es ja sonst auch nicht machen. Die zusätzlichen Informationen liegen dann im Verlauf.
Damit hätte man ein einfaches deterministisches Modell, abhängig von 2-3 Usereinstellungen und den bei den 1.500 BZ-Messungen in der Datei beiliegenden Events.